Re: Eliminating CA-Optimizer

[Mark Jacobs - Listserv]

There's a file on cbttape.org, File841, that allows programs compiled 
with CA-Optimizer to continue to execute without recompiling and without 
needing the Optimizer run time libraries.


Mark Jacobs


Charles Mills 
June 2, 2017 at 6:15 PM
The real question is "do they have a contractual right to run the 
programs after the license is terminated?"


I don't know the answer, but that is the real question. If the answer 
is yes, then if the programs do not continue to work, they have a 
legal beef with CA. If the answer is no, then even if they continue to 
work, they are risking embarrassment and damages if they continue to 
run the programs.


That's a question they ought to be able to answer by looking at their 
agreement with CA.


Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
On Behalf Of Tony Thigpen

Sent: Friday, June 2, 2017 2:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Eliminating CA-Optimizer

We support an old OS/390 (yep!) system that is slowly being eliminated.
To cut costs, the customer is asking about eliminating CA-Optimizer.

1) Would all the Cobol programs require re-compiling?
2) Or, will the run-time library continue to work once the license is 
cancelled?


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


Please be alert for any emails that may ask you for login information 
or directs you to login via a link. If you believe this message is a 
phish or aren't sure whether this message is trustworthy, please send 
the original message as an attachment to 'phish...@timeinc.com'.




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

Re: Eliminating CA-Optimizer

[Charles Mills]

The real question is "do they have a contractual right to run the programs 
after the license is terminated?" 

I don't know the answer, but that is the real question. If the answer is yes, 
then if the programs do not continue to work, they have a legal beef with CA. 
If the answer is no, then even if they continue to work, they are risking 
embarrassment and damages if they continue to run the programs.

That's a question they ought to be able to answer by looking at their agreement 
with CA.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: Friday, June 2, 2017 2:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Eliminating CA-Optimizer

We support an old OS/390 (yep!) system that is slowly being eliminated. 
To cut costs, the customer is asking about eliminating CA-Optimizer.

1) Would all the Cobol programs require re-compiling?
2) Or, will the run-time library continue to work once the license is cancelled?

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

Re: Removing JES2 PRT and RMT definitions - Answered

[Jesse 1 Robinson]

I was going to tell you to wait, my application depends on that second printer! 
But even on a Friday, I could not. ;-) 

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Art Gutowski
Sent: Friday, June 02, 2017 7:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Removing JES2 PRT and RMT definitions - Answered

On Sun, 21 May 2017 16:26:56 +, Jesse 1 Robinson  
wrote:
>I was hoping that Tom W. or someone else from JES2 would chime in. 
>I don't recall having removed JES2 devices in a MAS, but I'll go out on 
>a limb with the observation that all-systems warm start is hardly ever 
>required for anything these days. Since the advent of dynamic 
>modification in the 90s, most changes can be implemented by command 
>alone, or at worst by command followed by single-system restart. That's 
>not transparency, but it's no worse than rolling IPL for any other purpose.
>I suggest just removing the definitions and see what happens.  
 
As was I.  I though I tie off the thread for the curious.  As suspected by Skip 
and others, single-member warm-start removed these devices from each member in 
a rolling IPL, thus a successful sweeping of some cosmic debris.  I cannot say 
whether a hot-start would have sufficed.

For the record, we removed several dozen printers, e.g.:
PRT(nnn) CLASS=ccc,...

two REMOTE definitions, e.g.:
RMT() DEVTYPE=tt,LUNAME=,...
R(nnn).PR(n) ...
R(nnn),RD(n) ...
R(nnn).PU(n) ...

and DESTIDs for the RMTs:
DESTID() DEST=NnnnR

I know there is a $DEL DEStid, but since we had to IPL for the others, I just 
let these roll off with the lot.  Since this experiment, I intend to follow up 
with:
1) RCF against the JES2 Init & Tuning Ref to clarify the minimum requirement 
for removal of such definitions
   (again, add and modify are spelled out, but I am wont to find such explicit 
description for delete)
2) RFE against JES2 to provide $DEL commands for other devices where 
possible/practical, such as PRTs and RMTs

Thanks and regards,
Art Gutowski
General Motors, LLC


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

Eliminating CA-Optimizer

[Tony Thigpen]

We support an old OS/390 (yep!) system that is slowly being eliminated. 
To cut costs, the customer is asking about eliminating CA-Optimizer.


1) Would all the Cobol programs require re-compiling?
2) Or, will the run-time library continue to work once the license is 
cancelled?


--
Tony Thigpen

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

Re: Strange issue in ISPF edit

[Porowski, Kenneth]

Most often I see this when BOUNDS (BNDS line command) are set.

I believe that by default an edit profile is set for each unique DSORG and LLQ 
pair so it could be carried over from editing a different dataset..



This email message and any accompanying materials may contain proprietary, 
privileged and confidential information of CIT Group Inc. or its subsidiaries 
or affiliates (collectively, “CIT”), and are intended solely for the 
recipient(s) named above.  If you are not the intended recipient of this 
communication, any use, disclosure, printing, copying or distribution, or 
reliance on the contents, of this communication is strictly prohibited.  CIT 
disclaims any liability for the review, retransmission, dissemination or other 
use of, or the taking of any action in reliance upon, this communication by 
persons other than the intended recipient(s).  If you have received this 
communication in error, please reply to the sender advising of the error in 
transmission, and immediately delete and destroy the communication and any 
accompanying materials.  To the extent permitted by applicable law, CIT and 
others may inspect, review, monitor, analyze, copy, record and retain any 
communications sent from or received at this email address.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Friday, June 02, 2017 3:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] Strange issue in ISPF edit

My co-worker noticed the following issue (error?) which I cannot explain:
A dataset JANEK.JANEK.LUDZIE, PS VBA, containing some output from RLIST command.
Note: JANEK is userid of the co-worker, LUDZIE can be translated to PEOPLE.
ISPF Editor - a command FIND does not find anything!
I have seen this - regular "E" line command in p.3.4, then F "APPL" and nothing 
was found, of course we have seen APPL on the screen. The same with any other 
string in the file.
Now, something really strange: any name change of LLQ causes the FIND command 
working again!
So the same dataset renamed to JANEK.JANEK.LUDZIE1 or JANEK.JANEK.LUDZI or 
JANEK.JANEK.LUDZIE.OLD and you can use FIND as usual!

The problem occured on one of our z/OS images, only JANEK userid was affected.
Something was in ISPPROF, because finally JANEK simple scratched ISPPROF 
library and re-logged on again. The issue disappeared.

However I'm curious what setting/component/gismo caused such strange behavior?

--
Radoslaw Skorupka
Lodz, Poland




==


--
 Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

 This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

 mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.


--
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: Obtaining Storage in a Client Address Space

[Joseph Reichman]

What I originally did was pass my TCB PSATOLD
To the SRB 

So in the SRB I csn have my TCB as the TCB=

In the storage macro as I am in control ( for most things in my address space ) 
I should know when new task gets created 



>> On Jun 2, 2017, at 2:34 PM, Greg Dyck  wrote:
>> 
>> On 6/2/2017 10:59 AM, Joseph Reichman wrote:
>> To clarify storage if not released is around for the life of the TCB I am
>> assuming TCB ASCBXTCB  is around for the life span of the address space
> 
> The answer is no, so step carefully.
> 
> ASCBXTCB is *not* a constant value for the life of the address space.
> 
> When the initiator or STC controller attaches a new task ASCBXTCB is reset to 
> be that task.
> 
> When the ASCBXTCB task terminates VSM frees any storage owned by that task 
> and then ASCBXTCB is reset to be the task which attached the terminating task.
> 
> Regards,
> Greg
> 
> --
> 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: Strange issue in ISPF edit

[Lizette Koehler]

First,

Yes, there is an ISPF List as well.  To join go to this URL

ISPFhttps://listserv.nd.edu/cgi-bin/wa?A0=ispf-l


Next, I have seen this behavior with a couple of things

You can just delete the ISP members in PROFILE and not lose other entries.

That BNDS are turned on

MIXED case

Other little things I have not come across


Best thing when this happens is to do 

PROF 99 (I always use 99 - however there ae less number to use)

Then look for what is turned on in the PROFILE.

Lizette





> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of R.S.
> Sent: Friday, June 02, 2017 12:47 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Strange issue in ISPF edit
> 
> My co-worker noticed the following issue (error?) which I cannot explain:
> A dataset JANEK.JANEK.LUDZIE, PS VBA, containing some output from RLIST
> command.
> Note: JANEK is userid of the co-worker, LUDZIE can be translated to PEOPLE.
> ISPF Editor - a command FIND does not find anything!
> I have seen this - regular "E" line command in p.3.4, then F "APPL" and
> nothing was found, of course we have seen APPL on the screen. The same with
> any other string in the file.
> Now, something really strange: any name change of LLQ causes the FIND command
> working again!
> So the same dataset renamed to JANEK.JANEK.LUDZIE1 or JANEK.JANEK.LUDZI or
> JANEK.JANEK.LUDZIE.OLD and you can use FIND as usual!
> 
> The problem occured on one of our z/OS images, only JANEK userid was
> affected.
> Something was in ISPPROF, because finally JANEK simple scratched ISPPROF
> library and re-logged on again. The issue disappeared.
> 
> However I'm curious what setting/component/gismo caused such strange
> behavior?
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> 
> 
> ==
> 
> 
> --
>  Treść tej wiadomości może zawierać informacje prawnie chronione Banku
> przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być
> jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś
> adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej
> przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie,
> rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie
> zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo,
> prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale
> usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub
> zapisane na dysku.
> 
>  This e-mail may contain legally privileged information of the Bank and is
> intended solely for business use of the addressee. This e-mail may only be
> received by the addressee and may not be disclosed to any third parties. If
> you are not the intended addressee of this e-mail or the employee authorized
> to forward it to the addressee, be advised that any dissemination, copying,
> distribution or any other similar activity is legally prohibited and may be
> punishable. If you received this e-mail by mistake please advise the sender
> immediately by using the reply facility in your e-mail software and delete
> permanently this e-mail including any copies of it either printed or saved to
> hard drive.
> 
>  mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
> www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII
> Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców
> KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r.
> kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696
> złotych.
> 
> 
> --
> 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: Strange issue in ISPF edit

[Dana Mitchell]

On Fri, 2 Jun 2017 21:46:32 +0200, R.S.  wrote:

>My co-worker noticed the following issue (error?) which I cannot explain:
>A dataset JANEK.JANEK.LUDZIE, PS VBA, containing some output from RLIST
>command.
>Note: JANEK is userid of the co-worker, LUDZIE can be translated to PEOPLE.
>ISPF Editor - a command FIND does not find anything!



Sounds like a setting saved in JANEK's  edit profile of LUDZIE.   Perhaps they 
had BNDS set really wierd where nothing was found?

BNDS   < >


Dana

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

Strange issue in ISPF edit

[R.S.]

My co-worker noticed the following issue (error?) which I cannot explain:
A dataset JANEK.JANEK.LUDZIE, PS VBA, containing some output from RLIST 
command.

Note: JANEK is userid of the co-worker, LUDZIE can be translated to PEOPLE.
ISPF Editor - a command FIND does not find anything!
I have seen this - regular "E" line command in p.3.4, then F "APPL" and 
nothing was found, of course we have seen APPL on the screen. The same 
with any other string in the file.
Now, something really strange: any name change of LLQ causes the FIND 
command working again!
So the same dataset renamed to JANEK.JANEK.LUDZIE1 or JANEK.JANEK.LUDZI 
or JANEK.JANEK.LUDZIE.OLD and you can use FIND as usual!


The problem occured on one of our z/OS images, only JANEK userid was 
affected.
Something was in ISPPROF, because finally JANEK simple scratched ISPPROF 
library and re-logged on again. The issue disappeared.


However I'm curious what setting/component/gismo caused such strange 
behavior?


--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
   


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

Re: Displacement of ASG View Direct and PRO/JCL

[Silvio Camplani]

We migrated ViewDirect to SEA TRMS a couple of years ago. Sea was very
helpful with the migration. The transition was very smooth, but we used
only the basic function of VD. Cost savings where significant for us.
Regards,

Silvio Camplani
zSeries Sr. Analyst, Systems Support
Bombardier


On Wed, May 31, 2017, at 05:58 AM, Steven Liston wrote:
> Do any members have exposure to displacement of ASG's View
> Direct and/or> PRO/JCL products?
> 
> Looking for experience of the displacement and migration exercise and> 
> timeframes therein (which I expect for View Direct would be directly
> related to the number of docs stored in the current repository).
> 
> Expect PRO/JCL would be fairly straightforward but View Direct perhaps> more 
> challenging.
> 
> 
> Regards.
> 
> --> 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: DFSORT Error message

[Ron Thomas]

Ok both the statements are working , as i have put the continuation character 
wrongly .

Regards
Ron T

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

[Fwd: BSAM, DCBBUFOF, DCBBLKSI and buffer sizes]

[Thomas David Rivers]

I think this only got posted to the bit.listserve and never
made it to the ibm-main mailing list... so - resending it.

  - Dave Rivers -

--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com


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

When BSAM reads a file that has a block prefix length
(the size of which is specified in DCBBUFOF) then the
block prefix is returned in the BSAM data (unlike QSAM
which skips over that data.)

And, there are several accomodations/requirements made
regarding the DCBBLKSI field and the sizes of buffers
BSAM might allocate.

However - it doesn't seem to be clear if you are doing your
own buffer allocation.

Does the size of the buffer need to simply be DCBBLKSI,
or should it be DCBBLKSI + DCBBUFOF ?

I found a note in the z/VM documentation that the size
needs to be the sum of the two values.

But - I found notes in the documentation of the DCB macro
that seem to indicate that the DCBBLKSI should _include_
the size specified but DCBBUFOF (that is, a block is a block,
and the DCBBUFOF is just the start of your data.)

The answer also might be dependent on the the question
of ASCII tape files (RECFM=D...)

I'm not finding the documentation very clear on this point,
does someone know the definitive answer - or can they
point me to where in the doc the answer resides?   I've waded
through many macro parm definitions and DFSMS manuals...

 - Thanks! -
 - Dave Rivers -


--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
--- End Message ---

Re: Obtaining Storage in a Client Address Space

[Greg Dyck]

On 6/2/2017 10:59 AM, Joseph Reichman wrote:

To clarify storage if not released is around for the life of the TCB I am
assuming TCB ASCBXTCB  is around for the life span of the address space


The answer is no, so step carefully.

ASCBXTCB is *not* a constant value for the life of the address space.

When the initiator or STC controller attaches a new task ASCBXTCB is 
reset to be that task.


When the ASCBXTCB task terminates VSM frees any storage owned by that 
task and then ASCBXTCB is reset to be the task which attached the 
terminating task.


Regards,
Greg

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

Re: Anybody else timing out sending dumps to testcase?

[Tom Conley]

On 6/2/2017 1:33 PM, Jack J. Woehr wrote:

Pinnacle wrote:
I keep timing out trying to get a data connection to 
testcase.boulder.ibm.com.  Anybody else?


Regards,
Tom Conley



Widely reported network outage Level 3. I think it's over now.



Thanks Jack, all worky now.

Tom

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

Re: Anybody else timing out sending dumps to testcase?

[Jack J. Woehr]

Pinnacle wrote:

I keep timing out trying to get a data connection to testcase.boulder.ibm.com.  
Anybody else?

Regards,
Tom Conley



Widely reported network outage Level 3. I think it's over now.

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: Anybody else timing out sending dumps to testcase?

[Don Williams]

Have you verified that FTP SSL can pass thru your firewall?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pinnacle
Sent: Friday, June 02, 2017 1:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Anybody else timing out sending dumps to testcase?

I keep timing out trying to get a data connection to testcase.boulder.ibm.com.  
Anybody else?

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

Anybody else timing out sending dumps to testcase?

[Pinnacle]

I keep timing out trying to get a data connection to 
testcase.boulder.ibm.com.  Anybody else?


Regards,
Tom Conley

--
 



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

Re: DFSORT Error message

[Elardus Engelbrecht]

Sri h Kolusu wrote:

>Not really. DFSORT does NOT care about the sequence of the keywords.  You can 
>have them in any order. 

That is good, I was just reading those 'train tracks' schematics and a$$umed 
the keyword sequence could be a problem.
Many thanks.

Groete / Greetings
Elardus Engelbrecht

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

Re: strcasecmp() comparing punctuation in ASCII?

[Kirk Wolf]

"%" ahead of "*" would be consistent with the collation sequence defined by
the "POSIX C" locale:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.cbcpx01/cloc.htm

and here it says:
"The POSIX C locale uses the ASCII collation sequence; the first 128 ASCII
characters are defined in the collation sequence, and the remaining EBCDIC
characters are at the end of the collating sequence. "
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.cbcpx01/clocdif.htm#clocdif

If this is what you are seeing, then strcasecmp() is collating based on the
current LC_COLLATE / locale.   That's not what the standard says, assuming
that IBM's "POSIX C" locale is the "POSIX" locale referenced by the
standard.   Or IBM interpreted the standard to mean that POSIX on an EBCDIC
machine should sort according to ASCII byte order, which make sense
although breaks the letter of the law.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Fri, Jun 2, 2017 at 10:32 AM, Charles Mills  wrote:

> I had never paid any attention to what the locale was. I called
> setlocale() (yes, you use setlocale() to get the locale!) and the answer
> was "C". And yes, we are POSIX(ON).
>
> I am not seeing the behavior you ascribe to the standard. In the original
> issue I detected, "%" strcasecmp()'ed ahead of "*". Those characters should
> be unaffected by tolower(), and x'6C' (%) would certainly strcmp() after
> x'5C' (*). (My assumption at the time was that I had a bug and was not
> sorting the table as I intended.)
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Kirk Wolf
> Sent: Friday, June 2, 2017 7:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: strcasecmp() comparing punctuation in ASCII?
>
> The IEEE Std 1003.1, 2004 Edition was mentioned, but please note that it
> says this:
>
> "In the POSIX locale, *strcasecmp*() and *strncasecmp*() shall behave as
> if the strings had been converted to lowercase and then a byte comparison
> performed. *The results are unspecified in other locales.*"
>
> This is interesting in that it points to the next question:  what locale
> are you running under?
>
> The strcasecmp() function in XLC/C++ is poorly documented.  It only says:
>  "The strcasecmp() function is locale-sensitive".
>
> In z/OS XLC/C++, the default if you are running POSIX(ON) is the "POSIX C"
> locale.
> If this is the case for you, then the above statement from the standard
> would mean that:
>
> strcasecmp(a,b)  ==  strcmp(tolower(a), tolower(b))
>  # assuming a tolower(char*) function based on tolower(char)
>
> But you aren't seeing this.
>
> So, either:
>
> a) you aren't running with the POSIX C locale  (where the collation of
> strcasecmp() is undefined by the standard).
>
> b) you are running with the POSIX C locale, but IBM didn't follow the
> standard.
>
> According to the XLC/C++ doc:
> " The POSIX C locale uses the ASCII collation sequence; the first 128
> ASCII characters are defined in the collation sequence, and the remaining
> EBCDIC characters are at the end of the collating sequence."
>
> Is this what you are seeing?  If so, then XLC/C++ strcasecmp() uses
> LC_COLLATE for the POSIX C locale (and not byte comparison as specified by
> the standard).   Or maybe locale "POSIX C" != "POSIX".  Who knows.
>
> Note:  if you are using the uppercase of a word/phrase as a key, you might
> consider saving the uppercase/lowercase key and then using strcmp() or
> strcoll() to compare.Or you could define your own collation sequence
> via a translate table and then use the translated string as the key with
> strcmp().
> Using strcmp() for things like sort will probably be much faster anyway
> since it will be inlined using the CLST instruction, wherease strcasecmp()
> will be a function call.
>
> --
> 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

Obtaining Storage in a Client Address Space

[Joseph Reichman]

Hi

 

I saw the example of Storage Obtain in Client Address space in the Extended
Addressability guide. I also came across a post by Peter Relson mentioning
that the owning TCB 

Would be the xmem tcb ASCBXTCB. Would this storage be valid for as long the
address space alive ?

 

To clarify storage if not released is around for the life of the TCB I am
assuming TCB ASCBXTCB  is around for the life span of the address space

 

I do plan to release the storage rather quickly just wanted to know if my
assumption is correct, in addition when I do the release I would use
TCB=ASCBXTCB as the default is PSATOLD

  

Thanks


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

Re: strcasecmp() comparing punctuation in ASCII?

[Charles Mills]

I had never paid any attention to what the locale was. I called setlocale() 
(yes, you use setlocale() to get the locale!) and the answer was "C". And yes, 
we are POSIX(ON).

I am not seeing the behavior you ascribe to the standard. In the original issue 
I detected, "%" strcasecmp()'ed ahead of "*". Those characters should be 
unaffected by tolower(), and x'6C' (%) would certainly strcmp() after x'5C' 
(*). (My assumption at the time was that I had a bug and was not sorting the 
table as I intended.)

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kirk Wolf
Sent: Friday, June 2, 2017 7:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: strcasecmp() comparing punctuation in ASCII?

The IEEE Std 1003.1, 2004 Edition was mentioned, but please note that it says 
this:

"In the POSIX locale, *strcasecmp*() and *strncasecmp*() shall behave as if the 
strings had been converted to lowercase and then a byte comparison performed. 
*The results are unspecified in other locales.*"

This is interesting in that it points to the next question:  what locale are 
you running under?

The strcasecmp() function in XLC/C++ is poorly documented.  It only says:
 "The strcasecmp() function is locale-sensitive".

In z/OS XLC/C++, the default if you are running POSIX(ON) is the "POSIX C"
locale.
If this is the case for you, then the above statement from the standard would 
mean that:

strcasecmp(a,b)  ==  strcmp(tolower(a), tolower(b))
 # assuming a tolower(char*) function based on tolower(char)

But you aren't seeing this.

So, either:

a) you aren't running with the POSIX C locale  (where the collation of
strcasecmp() is undefined by the standard).

b) you are running with the POSIX C locale, but IBM didn't follow the standard.

According to the XLC/C++ doc:
" The POSIX C locale uses the ASCII collation sequence; the first 128 ASCII 
characters are defined in the collation sequence, and the remaining EBCDIC 
characters are at the end of the collating sequence."

Is this what you are seeing?  If so, then XLC/C++ strcasecmp() uses LC_COLLATE 
for the POSIX C locale (and not byte comparison as specified by
the standard).   Or maybe locale "POSIX C" != "POSIX".  Who knows.

Note:  if you are using the uppercase of a word/phrase as a key, you might 
consider saving the uppercase/lowercase key and then using strcmp() or
strcoll() to compare.Or you could define your own collation sequence
via a translate table and then use the translated string as the key with 
strcmp().
Using strcmp() for things like sort will probably be much faster anyway since 
it will be inlined using the CLST instruction, wherease strcasecmp() will be a 
function call.

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

Re: DFSORT Error message

[Sri h Kolusu]

>>After RTFM, I see you have the sequence incorrect.

Elardus,

Not really. DFSORT does NOT care about the sequence of the keywords.  You 
can have them in any order. 

OP's original statement is just missing a continuation character which 
Dave betten( thanks Dave) pointed out.  By adding the continuation 
character he should be able to get the desired results without making any 
additional changes

So OP's original statements are good provided that he added the 
continuation character hyphen (- ) before 73rd byte

+1+2+3+4+5+6+7---
//TOOLINDD * 
 SELECT FROM(SORTIN) TO(SORTF1) ON(16,50,CH) DISCARD(SORTF2) FIRST - 
 USING(CTL1) 
/* 

Ron Thomas wrote : >>>I have given as below, but still the issue is there

SELECT FROM(SORTIN) TO(SORTF1) ON(16,50,CH) DISCARD(SORTF2) FIRST  -
USING(CTL1)

Ron,

Are you sure you added the continuation character before 73rd byte ?  Show 
us the complete error messages after you added the continuation character. 
 

Thanks,
Kolusu
DFSORT Development
IBM Corporation

IBM Mainframe Discussion List  wrote on 
06/02/2017 06:53:34 AM:

> From: Elardus Engelbrecht 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 06/02/2017 06:54 AM
> Subject: Re: DFSORT Error message
> Sent by: IBM Mainframe Discussion List 
> 
> Ron Thomas wrote:
> 
> After RTFM, I see you have the sequence incorrect.
> 
> Change 
> 
> > SELECT FROM(SORTIN) TO(SORTF1) ON(16,50,CH) DISCARD(SORTF2) FIRST
> > USING(CTL1)
> 
> to
> 
>  SELECT FROM(SORTIN) TO(SORTF1) DISCARD(SORTF2) ON(16,50,CH)  FIRST - 
>  USING(CTL1)
> 
> Let us know if this works or not?
> 
> Groete / Greetings
> Elardus Engelbrecht
> 
> --
> 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: ISPF ZSTART

[Tom Conley]

On 6/2/2017 10:10 AM, PINION, RICHARD W. wrote:

I am testing the ISPF functionality of the ZSTART profile variable on z/OS 2.2 
systems.  On one system it works.  On
another system we get "Invalid command" as the error message on the ISPF 
primary menu.  I press the help key and
I get the message "The command you entered ZSTART is not recognized".  These 
are two different systems each with
their own sets of res packs and SMP/E.  I've checked SMP/E for LMOD's ISRPCP, 
ALIAS ISPF, and they are at the same
level.

The system where ZSTART functionality does not work we have NEWERA IMAGE FOCUS 
ENVIRONMENT.  I'm wondering
if that might be the issue.



Richard,

There are more than a few APARs for ZSTART.  I'd apply all the 
maintenance and work from there.


Regards,
Tom Conley

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

Re: Removing JES2 PRT and RMT definitions - Answered

[Art Gutowski]

On Sun, 21 May 2017 16:26:56 +, Jesse 1 Robinson  
wrote:
>I was hoping that Tom W. or someone else from JES2 would chime in. 
>I don't recall having removed JES2 devices in a MAS, but I'll go out on a limb 
>with the observation that all-systems warm start is hardly ever required for 
>anything these days. Since the advent of dynamic modification in the 90s, 
>most changes can be implemented by command alone, or at worst by 
>command followed by single-system restart. That's not transparency, but 
>it's no worse than rolling IPL for any other purpose. 
>I suggest just removing the definitions and see what happens.  
 
As was I.  I though I tie off the thread for the curious.  As suspected by Skip 
and others, single-member warm-start removed these devices from each member in 
a rolling IPL, thus a successful sweeping of some cosmic debris.  I cannot say 
whether a hot-start would have sufficed.

For the record, we removed several dozen printers, e.g.:
PRT(nnn) CLASS=ccc,...

two REMOTE definitions, e.g.:
RMT() DEVTYPE=tt,LUNAME=,...
R(nnn).PR(n) ...
R(nnn),RD(n) ...
R(nnn).PU(n) ...

and DESTIDs for the RMTs:
DESTID() DEST=NnnnR

I know there is a $DEL DEStid, but since we had to IPL for the others, I just 
let these roll off with the lot.  Since this experiment, I intend to follow up 
with:
1) RCF against the JES2 Init & Tuning Ref to clarify the minimum requirement 
for removal of such definitions
   (again, add and modify are spelled out, but I am wont to find such explicit 
description for delete)
2) RFE against JES2 to provide $DEL commands for other devices where 
possible/practical, such as PRTs and RMTs

Thanks and regards,
Art Gutowski
General Motors, LLC

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

ISPF ZSTART

[PINION, RICHARD W.]

I am testing the ISPF functionality of the ZSTART profile variable on z/OS 2.2 
systems.  On one system it works.  On
another system we get "Invalid command" as the error message on the ISPF 
primary menu.  I press the help key and
I get the message "The command you entered ZSTART is not recognized".  These 
are two different systems each with
their own sets of res packs and SMP/E.  I've checked SMP/E for LMOD's ISRPCP, 
ALIAS ISPF, and they are at the same
level.

The system where ZSTART functionality does not work we have NEWERA IMAGE FOCUS 
ENVIRONMENT.  I'm wondering
if that might be the issue.

FIRST TENNESSEE

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

Re: DFSORT Error message

[Ron Thomas]

Thanks a lot . it worked !  

Regards
Ron T

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

Re: strcasecmp() comparing punctuation in ASCII?

[Kirk Wolf]

The IEEE Std 1003.1, 2004 Edition was mentioned, but please note that it
says this:

"In the POSIX locale, *strcasecmp*() and *strncasecmp*() shall behave as if
the strings had been converted to lowercase and then a byte comparison
performed. *The results are unspecified in other locales.*"

This is interesting in that it points to the next question:  what locale
are you running under?

The strcasecmp() function in XLC/C++ is poorly documented.  It only says:
 "The strcasecmp() function is locale-sensitive".

In z/OS XLC/C++, the default if you are running POSIX(ON) is the "POSIX C"
locale.
If this is the case for you, then the above statement from the standard
would mean that:

strcasecmp(a,b)  ==  strcmp(tolower(a), tolower(b))
 # assuming a tolower(char*) function based on tolower(char)

But you aren't seeing this.

So, either:

a) you aren't running with the POSIX C locale  (where the collation of
strcasecmp() is undefined by the standard).

b) you are running with the POSIX C locale, but IBM didn't follow the
standard.

According to the XLC/C++ doc:
" The POSIX C locale uses the ASCII collation sequence; the first 128 ASCII
characters are defined in the collation sequence, and the remaining EBCDIC
characters are at the end of the collating sequence."

Is this what you are seeing?  If so, then XLC/C++ strcasecmp() uses
LC_COLLATE for the POSIX C locale (and not byte comparison as specified by
the standard).   Or maybe locale "POSIX C" != "POSIX".  Who knows.

Note:  if you are using the uppercase of a word/phrase as a key, you might
consider saving the uppercase/lowercase key and then using strcmp() or
strcoll() to compare.Or you could define your own collation sequence
via a translate table and then use the translated string as the key with
strcmp().
Using strcmp() for things like sort will probably be much faster anyway
since it will be inlined using the CLST instruction, wherease strcasecmp()
will be a function call.

More information on XLC/C++ locales:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.cbcpx01/cloc.htm


Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Fri, Jun 2, 2017 at 8:19 AM, Charles Mills  wrote:

> A couple of takeaways from all of this, at least for me:
>
> 1. Rather surprisingly, strcmp() and strcasecmp() do not return the same
> results *for strings that are not mixed case*! For example, for ("ABC",
> "123") strcmp() would return < but strcasecmp() would return > (untested).
> Consider the following bit of program logic, which would fail: Build a
> table
> of userid's from some system source. Because they come from the system they
> are all uppercase, so they could be sorted using strcmp(). When a user
> enters a userid, look it up in the table using a binary search. Since the
> user might enter the id in mixed case, search using strcasecmp(). The
> binary
> search would fail. (Yes, you could first uppercase the user input and use
> strcmp(). This is an illustrative example, not a "problem.")
>
> 2. One has to be very careful mixing strcasecmp() with roll-your-own
> compares such as if ( tolower(left[i]) != tolower(right[i]) ) ... I am
> checking my code for this issue.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Charles Mills
> Sent: Thursday, June 1, 2017 4:45 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: strcasecmp() comparing punctuation in ASCII?
>
> > strcasecmp() is obliged to convert all upper-case letters into
> > lower-case
> for the comparison
>
> I don't think it is as simple-minded as that (no offense -- you're not
> simple-minded either ).
>
> I think @John McKown pretty much nailed it. It's an "abstract" compare that
> just happens (well, a little more than just happens) to largely conform to
> ASCII.
>
> I think the -37 and 122 confirms that it is not a simple "subtract one
> ASCII
> value from another." And yes, I picked 'Z' and '0' specifically because
> they
> order differently ASCII versus EBCDIC. I've deleted my test code now but an
> interesting case would be 'A' and 'b', which differ in order between EBCDIC
> and ASCII also. A guess would be that the result would be +1, because they
> should be one entry apart in the abstract table, unlike their code points,
> which are x'20' or x'40' apart. ('A' and 'a' of course compare equal --
> that's the whole point, isn't it?)
>
> Yes, the results were astonishing. I assumed a bug in my code.
>
> My code is not only working correctly, it's superfluous! I do initial
> development and alpha test on Windows. I have some
> hard-coded-in-collating-order tables that I binary search. Most of them use
> all-alpha keys and so that order does not matter ASCII (Windows) versus
> EBCDIC (MVS). A few tables have mixed alpha, numerics and/or punctuation
> and
> so those I sort into collating sequence on start-up. Well, I needn't have
> bothered! As you indicate, 

Re: Displacement of ASG View Direct and PRO/JCL

[Porowski, Kenneth]

Cheryl Watson is the new List Mom as of 3/31/2017.  I believe John is now fully 
retired unless he still lurks somewhere.  I haven't seen any traffic for months 
but a post usually does get replies.

Ken



This email message and any accompanying materials may contain proprietary, 
privileged and confidential information of CIT Group Inc. or its subsidiaries 
or affiliates (collectively, “CIT”), and are intended solely for the 
recipient(s) named above.  If you are not the intended recipient of this 
communication, any use, disclosure, printing, copying or distribution, or 
reliance on the contents, of this communication is strictly prohibited.  CIT 
disclaims any liability for the review, retransmission, dissemination or other 
use of, or the taking of any action in reliance upon, this communication by 
persons other than the intended recipient(s).  If you have received this 
communication in error, please reply to the sender advising of the error in 
transmission, and immediately delete and destroy the communication and any 
accompanying materials.  To the extent permitted by applicable law, CIT and 
others may inspect, review, monitor, analyze, copy, record and retain any 
communications sent from or received at this email address.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Longnecker, Dennis
Sent: Thursday, June 01, 2017 2:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Displacement of ASG View Direct and PRO/JCL

The list is still maintained, but not by John.  Very little traffic on it.

Dennis

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Finnell
Sent: Thursday, June 1, 2017 1:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Displacement of ASG View Direct and PRO/JCL

Does John Anderson still maintain his ISV list in Canada? I googled a little 
but there's tons of Andersons.


In a message dated 6/1/2017 3:28:55 A.M. Central Daylight Time, 
sipp...@sg.ibm.com writes:

Adding  to the list of candidate alternatives, for ASG-ViewDirect it might be 
IBM  Tivoli Output Manager for z/OS or IBM Content Manager OnDemand for z/OS.  
For ASG-PRO/JCL, I agree with the RES suggestion. The full  product


--
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: DFSORT Error message

[Elardus Engelbrecht]

Ron Thomas wrote:

After RTFM, I see you have the sequence incorrect.

Change 

> SELECT FROM(SORTIN) TO(SORTF1) ON(16,50,CH) DISCARD(SORTF2) FIRST
> USING(CTL1)

to

 SELECT FROM(SORTIN) TO(SORTF1) DISCARD(SORTF2) ON(16,50,CH)  FIRST - 
 USING(CTL1)

Let us know if this works or not?

Groete / Greetings
Elardus Engelbrecht

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

Re: strcasecmp() comparing punctuation in ASCII?

[John McKown]

On Fri, Jun 2, 2017 at 8:41 AM, Allan Staller  wrote:

> John,
>
> I appreciate your attention to detail, but you have way too much
> time on your hands! 
>

​Yes, I do. Sometimes. ​

-- 
Windows. A funny name for a operating system that doesn't let you see
anything.

Maranatha! <><
John McKown

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

Re: DFSORT Error message

[Elardus Engelbrecht]

Ron Thomas wrote:

>I have given as below, but still the issue is there

>SELECT FROM(SORTIN) TO(SORTF1) ON(16,50,CH) DISCARD(SORTF2) FIRST  -
>USING(CTL1)

Please post the message(s).

What version of DFSORT and z/OS are you using?

I think your statement is now finally correct, but I am now RTFM to see if your 
statements are correct or not...

Groete / Greetings
Elardus Engelbrecht

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

Re: strcasecmp() comparing punctuation in ASCII?

[Allan Staller]

John,

I appreciate your attention to detail, but you have way too much time 
on your hands! 



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Friday, June 2, 2017 7:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: strcasecmp() comparing punctuation in ASCII?

On Thu, Jun 1, 2017 at 10:32 PM, Paul Gilmartin < 
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 1 Jun 2017 18:23:09 -0400, Thomas David Rivers wrote:
> >>
> >I find that very odd...
> >
> >strcasecmp() is obliged to convert all upper-case letters into 
> >lower-case for the comparison.
> >
> Wouldn't it be a fiasco if it effectively waffled on ligatures?
>

Hum, I can't see where ligatures are of any concern. Assuming that I understand 
them, they are just a result of very tight kerning of two separate letters. 
E.g. "tucking" the "i" under the "roof" of the letter "F". In memory this is 
still "Fi" - two separate runes (in Go speak - they distinguish "character" 
versus "rune" or "UNICODE code point". ref:
https://blog.golang.org/strings)
[quote]
​...​

Code points, characters, and runes

We've been very careful so far in how we use the words "byte" and "character". 
That's partly because strings hold bytes, and partly because the idea of 
"character" is a little hard to define. The Unicode standard uses the term 
"code point" to refer to the item represented by a single value. The code point 
U+2318, with hexadecimal value 2318, represents the symbol ⌘. (For lots more 
information about that code point, see its Unicode
page.)

To pick a more prosaic example, the Unicode code point U+0061 is the lower case 
Latin letter 'A': a.

But what about the lower case grave-accented letter 'A', à? That's a character, 
and it's also a code point (U+00E0), but it has other representations. For 
example we can use the "combining" grave accent code point, U+0300, and attach 
it to the lower case letter a, U+0061, to create the same character à. In 
general, a character may be represented by a number of different sequences of 
code points, and therefore different sequences of UTF-8 bytes.

The concept of character in computing is therefore ambiguous, or at least 
confusing, so we use it with care. To make things dependable, there are 
normalization techniques that guarantee that a given character is always 
represented by the same code points, but that subject takes us too far off the 
topic for now. A later blog post will explain how the Go libraries address 
normalization.

"Code point" is a bit of a mouthful, so Go introduces a shorter term for the 
concept: rune. The term appears in the libraries and source code, and means 
exactly the same as "code point", with one interesting addition.


[quote/]
​

>
> -- gil
>

--
Windows. A funny name for a operating system that doesn't let you see anything.

Maranatha! <><
John McKown

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


::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.




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

Re: strcasecmp() comparing punctuation in ASCII?

[Charles Mills]

A couple of takeaways from all of this, at least for me:

1. Rather surprisingly, strcmp() and strcasecmp() do not return the same
results *for strings that are not mixed case*! For example, for ("ABC",
"123") strcmp() would return < but strcasecmp() would return > (untested).
Consider the following bit of program logic, which would fail: Build a table
of userid's from some system source. Because they come from the system they
are all uppercase, so they could be sorted using strcmp(). When a user
enters a userid, look it up in the table using a binary search. Since the
user might enter the id in mixed case, search using strcasecmp(). The binary
search would fail. (Yes, you could first uppercase the user input and use
strcmp(). This is an illustrative example, not a "problem.")

2. One has to be very careful mixing strcasecmp() with roll-your-own
compares such as if ( tolower(left[i]) != tolower(right[i]) ) ... I am
checking my code for this issue.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Thursday, June 1, 2017 4:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: strcasecmp() comparing punctuation in ASCII?

> strcasecmp() is obliged to convert all upper-case letters into 
> lower-case
for the comparison

I don't think it is as simple-minded as that (no offense -- you're not
simple-minded either ).

I think @John McKown pretty much nailed it. It's an "abstract" compare that
just happens (well, a little more than just happens) to largely conform to
ASCII.

I think the -37 and 122 confirms that it is not a simple "subtract one ASCII
value from another." And yes, I picked 'Z' and '0' specifically because they
order differently ASCII versus EBCDIC. I've deleted my test code now but an
interesting case would be 'A' and 'b', which differ in order between EBCDIC
and ASCII also. A guess would be that the result would be +1, because they
should be one entry apart in the abstract table, unlike their code points,
which are x'20' or x'40' apart. ('A' and 'a' of course compare equal --
that's the whole point, isn't it?)

Yes, the results were astonishing. I assumed a bug in my code.

My code is not only working correctly, it's superfluous! I do initial
development and alpha test on Windows. I have some
hard-coded-in-collating-order tables that I binary search. Most of them use
all-alpha keys and so that order does not matter ASCII (Windows) versus
EBCDIC (MVS). A few tables have mixed alpha, numerics and/or punctuation and
so those I sort into collating sequence on start-up. Well, I needn't have
bothered! As you indicate, lower_bound results are consistent between
Windows and MVS.
strcasecmp() is obliged to convert all upper-case letters into lower-case
for the comparison.

Lower-case 'z' in EBCDIC is 0xa9, '0' in EBCDIC is 0xf0.  0xA9 is less than
0xF0; so I would expect strcasecmp() to return a value less than zero.

But - as you point out - in ASCII, 'z' is 0x7a, and '0' is 0x30.  0x7a is
greater than 0x30, so on an ASCII platform I would expect this to return a
positive value (note that 0x7a - 0x30 is 74 - not the 122 that IBM returned,
although both are positive.)

IBM must be mapping the values to some abstract code-points and then
subtracting those...

It _would_ mean that the strcasecmp() results are consistent between ASCII
and EBCDIC environments... which might sometimes be a desirable
characteristic - and other times not...
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: EXTERNAL: Re: DR Failover

[Tom Marchant]

On Thu, 1 Jun 2017 19:18:06 -0400, Edward Finnell wrote:

>There were some really good user experiences on DR at SHARE.

One memorable comment from a DR experience presentation at SHARE 
many years ago after (IIRC) a flood in Chicago took out a data center. 
The presenter said that the reason things went the the way they did 
was that DR planning was their highest priority, second only to 
everything else.

-- 
Tom Marchant

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

Re: strcasecmp() comparing punctuation in ASCII?

[Charles Mills]

And of course on the mainframe we get in the habit of using character and byte 
nearly interchangeably. The C language does not help: it uses char to mean an 
8-bit integer.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Friday, June 2, 2017 5:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: strcasecmp() comparing punctuation in ASCII?

On Thu, Jun 1, 2017 at 10:32 PM, Paul Gilmartin < 
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 1 Jun 2017 18:23:09 -0400, Thomas David Rivers wrote:
> >>
> >I find that very odd...
> >
> >strcasecmp() is obliged to convert all upper-case letters into 
> >lower-case for the comparison.
> >
> Wouldn't it be a fiasco if it effectively waffled on ligatures?
>

Hum, I can't see where ligatures are of any concern. Assuming that I understand 
them, they are just a result of very tight kerning of two separate letters. 
E.g. "tucking" the "i" under the "roof" of the letter "F". In memory this is 
still "Fi" - two separate runes (in Go speak - they distinguish "character" 
versus "rune" or "UNICODE code point". ref:
https://blog.golang.org/strings)
[quote]
​...​

Code points, characters, and runes

We've been very careful so far in how we use the words "byte" and "character". 
That's partly because strings hold bytes, and partly because the idea of 
"character" is a little hard to define. The Unicode standard uses the term 
"code point" to refer to the item represented by a single value. The code point 
U+2318, with hexadecimal value 2318, represents the symbol ⌘. (For lots more 
information about that code point, see its Unicode
page.)

To pick a more prosaic example, the Unicode code point U+0061 is the lower case 
Latin letter 'A': a.

But what about the lower case grave-accented letter 'A', à? That's a character, 
and it's also a code point (U+00E0), but it has other representations. For 
example we can use the "combining" grave accent code point, U+0300, and attach 
it to the lower case letter a, U+0061, to create the same character à. In 
general, a character may be represented by a number of different sequences of 
code points, and therefore different sequences of UTF-8 bytes.

The concept of character in computing is therefore ambiguous, or at least 
confusing, so we use it with care. To make things dependable, there are 
normalization techniques that guarantee that a given character is always 
represented by the same code points, but that subject takes us too far off the 
topic for now. A later blog post will explain how the Go libraries address 
normalization.

"Code point" is a bit of a mouthful, so Go introduces a shorter term for the 
concept: rune. The term appears in the libraries and source code, and means 
exactly the same as "code point", with one interesting addition.
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: DR Failover

[R.S.]

W dniu 2017-06-02 o 00:24, Jesse 1 Robinson pisze:

Never got traction on two of my questions, which are independent of technology.

-- During a failover (test I would presume), who actually performs the DR 
procedure whatever it is? Sysprogs, operators, production control folks, or 
someone else? Has anyone dared to bring in a non-technical person like a 
manager? This question is crucial to business resiliency because, depending the 
reason for failover, your top technical folks may be indisposed for an extended 
duration.

-- If you stayed in the DR environment long enough to have captured/updated 
live customer data, how did you eventually return to the production 
environment? This question is crucial to business resiliency because at some 
point down the line, you have to return or, as the poem goes, settle in for a 
long winter's nap.


In my case the DR procedure is always performed by the youngest (hte 
least experienced) operator. It works, but this is mainframe.
For other system a bunch of admins try to perform it and sometimes they 
succeed. ;-)
Oh, BTW, we also know how to come back to primary site after it is 
rebuilt after real disaster, however that require some of our 
administrators to log on and review the jobs.


--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
   


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

Re: DFSORT Error message

[Ron Thomas]

I have given as below, but still the issue is there

SELECT FROM(SORTIN) TO(SORTF1) ON(16,50,CH) DISCARD(SORTF2) FIRST  -
USING(CTL1)

Thanks,
Ron T

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

Re: strcasecmp() comparing punctuation in ASCII?

[John McKown]

On Thu, Jun 1, 2017 at 10:32 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 1 Jun 2017 18:23:09 -0400, Thomas David Rivers wrote:
> >>
> >I find that very odd...
> >
> >strcasecmp() is obliged to convert all upper-case letters into lower-case
> >for the comparison.
> >
> Wouldn't it be a fiasco if it effectively waffled on ligatures?
>

Hum, I can't see where ligatures are of any concern. Assuming that I
understand them, they are just a result of very tight kerning of two
separate letters. E.g. "tucking" the "i" under the "roof" of the letter
"F". In memory this is still "Fi" - two separate runes (in Go speak - they
distinguish "character" versus "rune" or "UNICODE code point". ref:
https://blog.golang.org/strings)
[quote]
​...​

Code points, characters, and runes

We've been very careful so far in how we use the words "byte" and
"character". That's partly because strings hold bytes, and partly because
the idea of "character" is a little hard to define. The Unicode standard
uses the term "code point" to refer to the item represented by a single
value. The code point U+2318, with hexadecimal value 2318, represents the
symbol ⌘. (For lots more information about that code point, see its Unicode
page.)

To pick a more prosaic example, the Unicode code point U+0061 is the lower
case Latin letter 'A': a.

But what about the lower case grave-accented letter 'A', à? That's a
character, and it's also a code point (U+00E0), but it has other
representations. For example we can use the "combining" grave accent code
point, U+0300, and attach it to the lower case letter a, U+0061, to create
the same character à. In general, a character may be represented by a
number of different sequences of code points, and therefore different
sequences of UTF-8 bytes.

The concept of character in computing is therefore ambiguous, or at least
confusing, so we use it with care. To make things dependable, there are
normalization techniques that guarantee that a given character is always
represented by the same code points, but that subject takes us too far off
the topic for now. A later blog post will explain how the Go libraries
address normalization.

"Code point" is a bit of a mouthful, so Go introduces a shorter term for
the concept: rune. The term appears in the libraries and source code, and
means exactly the same as "code point", with one interesting addition.


[quote/]
​

>
> -- gil
>

-- 
Windows. A funny name for a operating system that doesn't let you see
anything.

Maranatha! <><
John McKown

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

Re: DFSORT Error message

[David Betten]

I think USING is a parameter of the SELECT but ICETOOL is seeing it as a
separate statement.  Change the end of your SELECT statement to include a
continuation character.


//TOOLINDD *
 SELECT FROM(SORTIN) TO(SORTF1) ON(16,50,CH) DISCARD(SORTF2) FIRST -
 USING(CTL1)


Have a nice day,
Dave Betten
z/OS Performance Specialist
Cloud and Systems Performance
IBM Corporation
email:  bet...@us.ibm.com


IBM Mainframe Discussion List  wrote on
06/02/2017 08:17:31 AM:

> From: Ron Thomas 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 06/02/2017 08:19 AM
> Subject: DFSORT Error message
> Sent by: IBM Mainframe Discussion List 
>
> Hello .
>
> I am trying to extract unique invoice numbers to a file using DFSORT
> ,ICETOOL and below is my control card.n The o/p i want to reformat it.
>
> I am getting the below error messages. could someone let me know
> where the issue is ?
>
> //TOOLINDD *
>  SELECT FROM(SORTIN) TO(SORTF1) ON(16,50,CH) DISCARD(SORTF2) FIRST
>  USING(CTL1)
> /*
> //CTL1CNTL DD *
>   OUTFIL FNAMES=SORTF1,OUTREC=(06,50)
>   OUTFIL FNAMES=SORTF2,OUTREC=(06,50)
> /*
>
>
> ICE627I 0 DFSORT CALL 0001 FOR SORT FROM SORTIN   TO OUTFIL   COMPLETED
> ICE628I 0 RECORD COUNT:  0429362
> ICE638I 0 NUMBER OF RECORDS RESULTING FROM CRITERIA:  0097455
> ICE602I 0 OPERATION RETURN CODE:  00
>
>USING(CTL1)
>$
> ICE614A 0 INVALID OPERATOR
> ICE602I 0 OPERATION RETURN CODE:  12
>
>
> Thanks
> Ron T
>
> --
> 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: DR Failover

[Dana Mitchell]

Our company actually declared a disaster after a flood in 1993 when faced with 
an extended power outage.  We got to the hot site and began working on the 
restore when a large enough truck mounted generator was obtained, so we didn't 
actually have to go through with it.  But it started me thinking about the 
process of coming back.   It seems most tests and plans are centered around how 
to restore operations and cut over to a hot/DR site, but at the time no one 
seemed to be considering how you come back.  When you declare a disaster, it's 
more or less a known quantity what kind of environment you will be moving into. 
 It is much more difficult to plan on how one comes back, you could be faced 
with a wide range of scenarios, from largely intact equipment with out of date 
data (would have been our case due to a power outage), to a smoldering crater, 
and anything in between.  

Dana

On Thu, 1 Jun 2017 22:24:24 +, Jesse 1 Robinson  
wrote:
 
>-- If you stayed in the DR environment long enough to have captured/updated 
>live customer data, how did you eventually return to the production 
>>environment? This question is crucial to business resiliency because at some 
>point down the line, you have to return or, as the poem goes, settle in for a 
>>long winter's nap.   


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

DFSORT Error message

[Ron Thomas]

Hello .

I am trying to extract unique invoice numbers to a file using DFSORT ,ICETOOL 
and below is my control card.n The o/p i want to reformat it. 

I am getting the below error messages. could someone let me know where the 
issue is ?

//TOOLINDD *
 SELECT FROM(SORTIN) TO(SORTF1) ON(16,50,CH) DISCARD(SORTF2) FIRST
 USING(CTL1)
/*
//CTL1CNTL DD *
  OUTFIL FNAMES=SORTF1,OUTREC=(06,50)
  OUTFIL FNAMES=SORTF2,OUTREC=(06,50)
/*


ICE627I 0 DFSORT CALL 0001 FOR SORT FROM SORTIN   TO OUTFIL   COMPLETED
ICE628I 0 RECORD COUNT:  0429362
ICE638I 0 NUMBER OF RECORDS RESULTING FROM CRITERIA:  0097455
ICE602I 0 OPERATION RETURN CODE:  00

   USING(CTL1)
   $
ICE614A 0 INVALID OPERATOR
ICE602I 0 OPERATION RETURN CODE:  12


Thanks
Ron T

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

Re: ES/9000 microcode

[Timothy Sipples]

Running Linux on an IBM 9221 will require the "vintage" patch and the (now
deprecated) 31-bit kernel. Historical details are available here:

http://linuxvm.org/penguinvm/programs/vintage/


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
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