Re: How can I determine MVS FQDSN from DD Name in Batch COBOL Program?

[Cameron Conacher]

Oh Yes,
I am an old fart,….
Tender Loving Care for the JOB Card …. = Time, Lines and Cards.

Again. I am just trying to creatively deal with a two sided coin here.
We want tracing dynamically available, but we do not want it available as SPOOL 
in Production.

Also, this allowed me to explore the MVS Control Blocks a little bit.

Thanks

…….Cameron

Note I will be OOO on PTO March 23 throough March 31 2024 inclusive.

From: IBM Mainframe Discussion List  On Behalf Of Sri 
Hari Kolusu
Sent: Tuesday, March 26, 2024 5:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How can I determine MVS FQDSN from DD Name in Batch COBOL Program?

>> Is your SPOOL so constrained that you are concerned about running out of 
>> space if a job issues even a few million lines of sysout? >> The issue is 
>> that we have so many JOBs over so many decades doing this. Cameron, Did you 
>> know




>> Is your SPOOL so constrained that you are concerned about running out of 
>> space if a job issues even a few million lines of sysout?

>> The issue is that we have so many JOBs over so many decades doing this.



Cameron,



Did you know that you can use LINES parm to cancel/Dump/Warning for the job?



https://www.ibm.com/docs/en/zos/3.1.0?topic=statement-lines-parameter



For example, if you code this on job card



//LINES=(20,CANCEL),



Then the job will be cancelled if it writes out more than 20,000 lines to Spool



You can dynamically insert that LINES parm into every job.



Thanks,

Kolusu







--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with 
the message: INFO IBM-MAIN


American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: How can I determine MVS FQDSN from DD Name in Batch COBOL Program?

[Cameron Conacher]

The issue is that we have so many JOBs over so many decades doing this.


Thanks

…….Cameron

Note I will be OOO on PTO March 23 throough March 31 2024 inclusive.

From: IBM Mainframe Discussion List  On Behalf Of Tom 
Marchant
Sent: Tuesday, March 26, 2024 4:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How can I determine MVS FQDSN from DD Name in Batch COBOL Program?

Is your SPOOL so constrained that you are concerned about running out of space 
if a job issues even a few million lines of sysout? -- Tom Marchant 
-- For 
IBM-MAIN subscribe


Is your SPOOL so constrained that you are concerned about running out of space 
if a job issues even a few million lines of sysout?



--

Tom Marchant



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with 
the message: INFO IBM-MAIN


American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: How can I determine MVS FQDSN from DD Name in Batch COBOL Program?

[Cameron Conacher]

Hello Paul,
That is almost exactly my approach, however I wanted to chase the Control 
Blocks, just in case someone "accidentally" sets the Parm to YES in Production, 
when SYSOUT has been assigned to SPOOL.
I want to keep them honest.

Thanks

...Cameron

Note I will be OOO on PTO March 23 throough March 31 2024 inclusive.

From: IBM Mainframe Discussion List  On Behalf Of 
Paul Feller
Sent: Tuesday, March 26, 2024 11:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How can I determine MVS FQDSN from DD Name in Batch COBOL Program?

I'm going to suggest something a little different. Let me say that I'm not 
against what Cameron is trying to do. I've done the run the control block thing 
and I've done the RDJFCB thing. In the original email the statement was made. 
"But in


I'm going to suggest something a little different.  Let me say that I'm not

against what Cameron is trying to do.  I've done the run the control block

thing and I've done the RDJFCB thing.



In the original email the statement was made.



"But in emergency, support could override SYSOUT=* with SYSOUT=mydatasetName

and my program will be able to determine we can honour the DISPLAYs."



I'm assuming that the override would be some type of JCL change.  Well what

about just adding a parm to the JCL that is used to indicate to do the

display or not to do the display.  Keep the SYSOUT as a FQDN, maybe a GDG

that only has two or three versions.



So now the COBOL code checks the parm to indicate how to handle the display

stuff.



Just a little different way of looking at things.





Paul



-Original Message-

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of

Kirk Wolf

Sent: Tuesday, March 26, 2024 10:46 AM

To: IBM-MAIN@LISTSERV.UA.EDU

Subject: Re: How can I determine MVS FQDSN from DD Name in Batch COBOL

Program?



IMO, a assembler subroutine that does RDJFCB is a better option than chasing

control blocks.   I wrote one that we call from our C++ product and its

about 120 lines of assembler code, with XPLINK linkage.   However, we use

EDCDSECT to convert the JFCB dsect to a C header so that you can look at

anything you want from C/C++.It's been very reliable for many years in

all sorts of use cases.



Kirk Wolf

Dovetailed Technologies

http:// 
>coztoolkit.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


American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a ?t? envoy? par un repr?sentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les exp?diteurs par courriel.

Ce courriel est r?serv? au seul destinataire indiqu? et peut renfermer des 
renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire 
pr?vu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez re?u ce courriel par erreur, veuillez en aviser 
l'exp?diteur par courriel et d?truire imm?diatement le courriel et toute pi?ce 
jointe. Merci.

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

Re: How can I determine MVS FQDSN from DD Name in Batch COBOL Program?

[Cameron Conacher]

Hello Kolusu,
I suppose the real answer here is that I was reading through the MVS Control 
Blocks manuals think h along the way and wondering.
I just went down a rabbit hole.
Chasing MVS Control Blocks.

Thanks

…….Cameron

Note I will be OOO on PTO March 23 throough March 31 2024 inclusive.

From: IBM Mainframe Discussion List  On Behalf Of Sri 
Hari Kolusu
Sent: Monday, March 25, 2024 9:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How can I determine MVS FQDSN from DD Name in Batch COBOL Program?

>> I did not really need the FQDSN. All I needed to know was whether or not 
>> SYSOUT was assign to SPOOL. Cameroon, Does this code handle Dynamically 
>> allocated Sysout dataset and XTIOT entries (i. e NON_VSAM_XTIOT=YES is set 
>> in SMS? Also,




>> I did not really need the FQDSN. All I needed to know was whether or not 
>> SYSOUT was assign to SPOOL.



Cameroon,



Does this code handle Dynamically allocated Sysout dataset and XTIOT  entries 
(i.e NON_VSAM_XTIOT=YES is set in SMS?



Also, I was wondering what is the need to traverse the entire TIOT when all you 
are interested in a single ddname SYSOUT?



BPXWDYN2 returns a variable named INRTTYP which is the " Requests the data set 
type. One of the following strings is returned: blanks, DUMMY, TERM, SYSIN, 
SYSOUT, or two hexadecimal digits as returned from SVC99."





Thanks,

Kolusu







--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with 
the message: INFO IBM-MAIN


American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: How can I determine MVS FQDSN from DD Name in Batch COBOL Program?

[Cameron Conacher]

Hello,
In case anyone needs this….. it seems to work so far.
I did not really need the FQDSN. All I needed to know was whether or not SYSOUT 
was assign to SPOOL.

*
* Work area for the MVS Control Block variables.
*
 01  WS-CONTROL-BLOCK-VARIABLES.
 05  WS-CBV-JOB-NUMBER   PIC X(08).
 05  WS-CBV-JOB-NAME PIC X(08).
 05  WS-CBV-PROGRAM-NAME PIC X(08).
 05  WS-CBV-PROC-STEP-NAME   PIC X(08).
 05  WS-CBV-JOB-STEP-NAMEPIC X(08).
 05  WS-CBV-USER-ID  PIC X(08).
 05  WS-CBV-USER-NAMEPIC X(20).
 05  WS-CBV-PROGRAMMER-NAME  PIC X(20).
 05  WS-CBV-GROUP-NAME   PIC X(20).
 05  WS-CBV-FOUR-BYTES.
 10  WS-CBV-FULL-WORDPIC S9(08) COMP.
 10  WS-CBV-PTR-UNAM REDEFINES WS-CBV-FULL-WORD
 POINTER.
 05  WS-CBV-SUB  PIC S9(04) COMP.
 05  WS-CBV-TIOELINK PIC X(01).
 88  WS-CBV-DDNAME-FOR-DSN  VALUE X'00'.
 88  WS-CBV-DDNAME-FOR-SPOOLVALUE X'02'.


*
* USED WHEN PARSING MVS CONTROL BLOCK DATA.
*
  01  LS-CB-POINTER-AREA-1. *> PSA
  05  LS-CB-POINTER POINTER OCCURS 512 TIMES.
*
* USED WHEN PARSING MVS CONTROL BLOCK DATA.
*
  01  LS-CB-POINTER-AREA-2.
  05  LS-CB-POINTER2 POINTER OCCURS 512 TIMES.
*
*



*
* Get Job Name, Job Step Name and Proc Step Name from
* TIOT Control Blocks.
* See Volume #4 of the MVS Data Areas Page #855.
*
 SET ADDRESS OF LS-CB-POINTER-AREA-1
  TO LS-CB-POINTER (136) *> TCB
 SET ADDRESS OF LS-CB-POINTER-AREA-2
  TO LS-CB-POINTER (004) *> TIOT
 MOVE LS-CB-POINTER-AREA-2 (1:8)
  TO WS-CBV-JOB-NAME   *> JOBNAME

 MOVE LS-CB-POINTER-AREA-2 (9:8)
  TO WS-CBV-PROC-STEP-NAME

 MOVE LS-CB-POINTER-AREA-2 (17:8)
  TO WS-CBV-JOB-STEP-NAME


*
* Iterate over all the DDNAME entries looking for SYSOUT.
* We want to know if it is assigned to SPOOL or not.
*
* In Production DISPLAYs are ignored, so if we are in
* Production and SYSOUT is being sent to the SPOOL, we want
* to be able to disable Tracing.
* On the other hand if SYSOUT is being sent to a DataSet,
* we want to honor the JOB Tracing Parameter for Production.
*
 PERFORM
 VARYING WS-CBV-SUB
FROM +25  *> Start of DDNAME Table
  BY +20  *> Size of DDNAME Table Entry
   UNTIL WS-CBV-SUB > 1120
  OR LS-CB-POINTER-AREA-2 (WS-CBV-SUB + 4:08) =
   LOW-VALUES  *> End of Table
  IF LS-CB-POINTER-AREA-2 (WS-CBV-SUB + 4:08) =
   'SYSOUT  '
 MOVE LS-CB-POINTER-AREA-2 (WS-CBV-SUB + 3:01)
  TO WS-CBV-TIOELINK *> Spool?
 MOVE +1120   TO WS-CBV-SUB  *> Stop Loop
  END-IF
 END-PERFORM

*
* Get Program Name and Job Number from JSCB Control Blocks.
*
 SET ADDRESS OF LS-CB-POINTER-AREA-2
  TO LS-CB-POINTER (46) *> JSCB
 MOVE LS-CB-POINTER-AREA-2 (361:8)
  TO WS-CBV-PROGRAM-NAME

 SET ADDRESS OF LS-CB-POINTER-AREA-2
  TO LS-CB-POINTER2 (80) *> SSIB
 MOVE LS-CB-POINTER-AREA-2 (13:8)
  TO WS-CBV-JOB-NUMBER *> JOBNUM

*
* Get RACF ID from ASCB Control Blocks.
*
 SET ADDRESS OF LS-CB-POINTER-AREA-1
  TO NULL
 SET ADDRESS OF LS-CB-POINTER-AREA-1
  TO LS-CB-POINTER (138) *> ASCB

 SET ADDRESS OF LS-CB-POINTER-AREA-2
  TO LS-CB-POINTER (28)  *> ASXB
 MOVE LS-CB-POINTER-AREA-2 (193:8)
  TO WS-CBV-USER-ID*> RACF ID

*
* Get RACF Group from ACEE Control Blocks.
*
 SET ADDRESS OF LS-CB-POINTER-AREA-2
  TO LS-CB-POINTER2 (51) *> ACEE
 MOVE LS-CB-POINTER-AREA-2 (31:8)
  TO WS-CBV-GROUP-NAME *> GROUP

*
* Get Long Name from UNAM Control Blocks.
*
 SET ADDRESS OF LS-CB-POINTER-AREA-1
  TO LS-CB-POINTER2 (26) *> UNAM
 MOVE ZEROTO WS-CBV-FULL-WORD
 MOVE LS-CB-POINTER-AREA-1 (1:1)
  TO WS-CBV-FOUR-BYTES (4:1)
 MOVE LS-CB-POINTER-AREA-1 (2:WS-CBV-FULL-WORD)
  TO WS-CBV-USER-NAME*> NAME
 .



Thanks

…….Cameron

Note I will be OOO on PTO March 23 throough March 31 2024 inclusive.

From: IBM Mainframe Discussion List  On Behalf Of Sri 
Hari Kolusu
Sent: Monday, March 25, 2024 12:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How can I determine MVS FQDSN from DD Name in Batch COBOL Program?

>> Why? Well I would like my COBOL program to allow 

How can I determine MVS FQDSN from DD Name in Batch COBOL Program?

[Cameron Conacher]

Hello.
Back again.
Previously I had inquired about retrieving RACF details from the MVS control 
Blocks at runtime.
Name I would like to retrieve the Fully Qualified Data set name for a specific 
DD (SYSOUT).

Why? Well I would like my COBOL program to allow COBOL Displays in Production 
ONLY when the User specified a FQDN.
If the JOB has SYSOUT DD *, then I will skip the COBOL displays to prevent 
filling the SPOOL.
But in emergency, support could override SYSOUT=* with SYSOUT=mydatasetName and 
my program will be able to determine we can honour the DISPLAYs.

Yeah, maybe this is a make work project?
Maybe the pain killers working over time?

Thanks


Cameron Conacher
Senior Engineer

American Express Canada Inc.
GCICS
2225 Sheppard Avenue East, Toronto, ON  M2J 5C2

cameron.conac...@aexp.com<mailto:cameron.conac...@aexp.com>
Office: 1-437-836-5265
Mobile: 1-416-409-5147

https://amex.webex.com/join/cameron.conacher

Note I will be OOO on PTO March 23 throough March 31 2024 inclusive.



American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a ?t? envoy? par un repr?sentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les exp?diteurs par courriel.

Ce courriel est r?serv? au seul destinataire indiqu? et peut renfermer des 
renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire 
pr?vu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez re?u ce courriel par erreur, veuillez en aviser 
l'exp?diteur par courriel et d?truire imm?diatement le courriel et toute pi?ce 
jointe. Merci.

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

Re: Line comments in DFSORT

[Cameron Conacher]

Yes indeed.
I like to use the asterisk in column one to comment the spirit of what I am 
attempting to do.
I use the short inline right sided comments to offer brief parm descriptions.

Thanks

…….Cameron

From: IBM Mainframe Discussion List  On Behalf Of Sri 
Hari Kolusu
Sent: Friday, March 8, 2024 10:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Line comments in DFSORT

>> And, using the example provided, we are able to add a comment to the first 
>> two lines but not the last line, since it does not have a hyphen? Cameron, 
>> That is true. But if you want you can add as many comment lines you want 
>> using *


>> And, using the example provided, we are able to add a comment to the first 
>> two lines but not the last line, since it does not have a hyphen?



Cameron,



That is true. But if you want you can add as many comment lines you want using 
* in column 1.



//TOOLIN   DD *

* Enter ICETOOL operators here

* My comment line - 1

* My comment line - 2

* My comment line - 3

* My comment line - 4



  COPY FROM(INPUTA) TO(OUTA)



/*





Thanks,

Kolusu

DFSORT Development

IBM Corporation







--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with 
the message: INFO IBM-MAIN


American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: Line comments in DFSORT

[Cameron Conacher]

Hello,
And, using the example provided, we are able to add a comment to the first two 
lines but not the last line, since it does not have a hyphen?


Thanks

…….Cameron

From: IBM Mainframe Discussion List  On Behalf Of Bob 
Stark
Sent: Friday, March 8, 2024 8:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Line comments in DFSORT

I found this in the ICETOOL doc: | Continuation can be indicated by a hyphen 
(-) after the operator or after any operand. The next operand must then be 
specified on the next line. For example: | SORT FROM(INDD) - | USING(ABCD) - | 
TO(OUTPUT1,OUTPUT2,OUTPUT3)


I found this in the ICETOOL doc:



| Continuation can be indicated by a hyphen (-) after the operator or after any 
operand. The next operand must then be specified on the next line. For example:

| SORT FROM(INDD) -

|USING(ABCD) -

|TO(OUTPUT1,OUTPUT2,OUTPUT3)

|

| Any characters specified after the hyphen are ignored.



Which shows me that line comments are a byproduct of the ICETOOL continuation 
logic, and not a core feature. From your earlier example, I thought that the # 
character had some significance, but now I see that it does not.



None of the examples in the doc show line comments being used.



I use the traditional "* in column 1" comment to show "Here is what is coming 
up in the next several lines of code", usually with a blank line in front, so 
that the eye can scan to each block of statements quickly.



I use line comments to explain the gory details of the code immediately to the 
left of it.



This is the style I learned as an Assembler programmer, and it carries forward 
to my work in many other languages.



DFSORT and ICETOOL code can be very complex, and is daunting for a new student, 
looking at it for the first time.



While teaching, we seek to have a stream of "Aha, I get what it is doing!" 
moments. Line comments help us to explain those gory details that lead to the 
"Light Bulb" moment.



The best thing about the DFSORT documentation is that there are numerous 
examples of different scenarios, with the code to handle that scenario. Other 
IBM products would do well to follow this approach.



Regards,

Bob Stark



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with 
the message: INFO IBM-MAIN


American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: Can DFSORT assign custom Return Code values?

[Cameron Conacher]

The situation is that I have three different environments.
If we are in development, lets ignore the email
If we are in pre-prod, let’s assume someone is perform a User Acceptance test.
If we are in production, we should jump in and deal with remediation.

When the email is sent, I have embedded Symbolics in the email text itself, 
meaning I need to use  //SYSUT1   DD  *,SYMBOLS=EXECSYS, with IEBGENER.

In this situation, I cannot put the email text in a PDS as I would not be able 
to use the SYSBOLS= clause with IEBGENER,
On the other hand I could put all the email text into a PDS member, and 
pre-process this email text performing all the Symbolic substitutions, and 
create a temp file that has already had all of the substitution performed, pass 
it to IEBGENER without the SYMBOLS= clause, and go from there.
Sri, showed me how to gather the available data from the existing System 
Symbolics, and I can pass other data I need via PARMs.
So I am all good to go now.

However, I am going to look into writing a tiny C program, that I can call as a 
utility to assign a return code value. Just to see what it takes.

I was looking to run a utility that would simply generate a Return Code value, 
I could use to conditionally execute a JOBSTEP.


Thanks

…….Cameron

From: IBM Mainframe Discussion List  On Behalf Of 
Michael Oujesky
Sent: Monday, March 4, 2024 12:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can DFSORT assign custom Return Code values?

Presuming these are three different z/OS instances. why not just use system 
symbols to make the determination of what environment is being used? Michael At 
10: 12 AM 3/4/2024, Sri Hari Kolusu wrote: >Content-Transfer-Encoding: base64>>


Presuming these are three different z/OS instances. why not just use

system symbols to make the determination of what environment is being used?



Michael



At 10:12 AM 3/4/2024, Sri Hari Kolusu wrote:

>Content-Transfer-Encoding: base64>> I was to be able to assign one

>of three different Return Code values (any value) that I can let

>check to determine if I am running in Development, Pre-Prod or

>Production, and then execute steps related to the specific environment.

>Not something I absolutely need since I could write a tiny program for this.

>

>Cameron,

>

>DFSORT has limited ability to set a return code but not the way you

>want. However, I think we can solve your issue quite easily by

>validating the symbol and only generating the steps that needs to

>run for that Symbolic. Remember DFSORT has the ability of reading

>the system symbols and determine the LPAR it is running.

>

>Please send an offline email with your complete requirement and I

>will show you a way to do it.

>

>Thanks,

>Kolusu

>DFSORT Development

>IBM Corporation

>

>--

>For IBM-MAIN subscribe / signoff / archive access instructions,

>send email to lists...@listserv.ua.edu 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


American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Can DFSORT assign custom Return Code values?

[Cameron Conacher]

Hello everyone,
From what I have read this is not possible, but I decided to throw it out there 
to see if something is possible.

I have a block of JCL with a bunch of steps.
I have symbolic parameters assigned. (JP1/JP2 SYSPLEX Symbolics for DFSORT)

I was looking for a Utility that would examine the value of a Symbolic and 
assign a User Return Coe value. RC1 = Development; RC2 = Pre-Production; RC3 = 
Production?
I need a Return Code value to be able to conditionally execute subsequent JOB 
steps. I cannot execute steps conditionally based on Symbolic Variable values.
IF Step001.RC = 0 ….Development

I could write a tine program to do this.
I was hunting around for a utility to do this.
DFSORT is my go to Utility but as mentioned, I believe it is not suitable for 
this task.
I believe I could set RC0 or RC4 or RC16. RC0 and RC4 generate a message and 
continue, but RC16 generates a message and terminates. I think this 
(Termination) would be unsuitable.

I was to be able to assign one of three different Return Code values (any 
value) that I can let check to determine if I am running in Development, 
Pre-Prod or Production, and then execute steps related to the specific 
environment.
Not something I absolutely need since I could write a tiny program for this.

Just curious, and I think my ADHD has just sent me down another rabbit hole 

I could do this in Easytrieve. Or COBOL. Or Assembler. Or Rexx. Or …..

Hope this makes sense.

Thanks


Cameron Conacher
Senior Engineer

American Express Canada Inc.
GCICS
2225 Sheppard Avenue East, Toronto, ON  M2J 5C2

cameron.conac...@aexp.com<mailto:cameron.conac...@aexp.com>
Office: 1-437-836-5265
Mobile: 1-416-409-5147

https://amex.webex.com/join/cameron.conacher




American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: Connect:Direct question

[Cameron Conacher]

Hello
A bit late to the party.
I use something like this.
Maybe it helps?

SYMBOL  = \"\ || :datatype= ||-
 || :xlate= ||  || :STRIP.BLANKS= || -
 || :permiss= ||  || :pipe= ||  -
 || :xlate.table= ||  || \:\ || \"\


Thanks

…….Cameron

From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Wednesday, January 31, 2024 9:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Connect:Direct question

I can make a suggestion. But if this fails, the following questions would need 
to be addressed. SYSOPTS=("STORCLAS=RKF1 DATACLAS=EXT") - Don't know if that 
will work. I've not worked on/with NDM on a daily basis for about 4 years now. 
Why do


I can make a suggestion. But if this fails, the following

questions would need to be addressed.



  SYSOPTS=("STORCLAS=RKF1 DATACLAS=EXT") -



Don't know if that will work. I've not worked on/with NDM on a daily basis for 
about 4 years now.



Why do you have to specify storclass and dataclas for the

receiving entity? Does it not have ACS rules to handle this?



Secondly, could you provide any error messages relative to the

sysopts processing?



One other thought: Can you do a run task on the other system to

define the dataset and then do the xfer?



Steve Thompson



On 1/31/2024 8:50 AM, Gadi Ben-Avi wrote:

> Hi,

> I am trying to transfer a file using Connect:Direct from one z/OS system to 
> another.

> I need to specify both STORCLAS and DATACLAS.

> This is what I am writing:

> CPYSEQ PROCESS-

>  SNODE=RTST

>   COPY1 COPY-

> FROM (DSN=G120NTN.KVTNKSP.UNLOAD-

>   DISP=SHR  -

>   PNODE -

>  ) -

> TO   (DSN=G120NTN.KVTNKSP.UNLOAD-

>   DISP=(NEW,CATLG)  -

>   SPACE=(CYL,(999,),RLSE)   -

>   SYSOPTS="STORCLAS=RKF1 DATACLAS=EXT" -

>   SNODE -

>  )

>

> And I keep getting errors.

>

> How to I specify more than one parameter in SYSOPTS. I've tried writing a 
> comma between the parameters with the same results.

>

> Thanks

>

> Gadi

>

>

>

>

>

> --

> For IBM-MAIN subscribe / signoff / archive access instructions,

> send email to lists...@listserv.ua.edu with 
> the message: INFO IBM-MAIN



--

Regards, Steve Thompson



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with 
the message: INFO IBM-MAIN


American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: How can I determine the User Name associated with the current Batch JOB RACF ID?

[Cameron Conacher]

Thanks very much.
I struggled at first, but finally got through.
This is perfect.!!

On Mon, Jan 29, 2024 at 9:31 AM Binyamin Dissen 
wrote:

> On Mon, 29 Jan 2024 13:36:51 +0000 Cameron Conacher
> <03cfc59146bb-dmarc-requ...@listserv.ua.edu> wrote:
>
> :>Good Morning,
> :>I know I can do this in CICS, but I am digging around to see if this can
> be done in a batch COBOL program.
> :>Basically, I just want to include Fred's Name in a report I generate,
> where Fred is the RACF ID associate with the currently executing Batch JOB.
> (a COBOL program).
> :>I could write something to call out to CICS (EXCI maybe) to get a name.
> :>But I wanted to know if there is anyway to do this by calling some
> routines from my Batch COBOL program.
>
> :>I am assuming right now, it is not possible since I have come up empty
> so far.
>
> You can get it from ACEEUNAM.
>
> https://www.microfocus.co.jp/manuals/ED23/html/HCOMCMCBLKS005.html shows
> how
> to locate MVS control blocks from COBOL.
>
> --
> Binyamin Dissen 
> http://www.dissensoftware.com
>
> Director, Dissen Software, Bar & Grill - Israel
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu 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: How can I determine the User Name associated with the current Batch JOB RACF ID?

[Cameron Conacher]

Thanks everyone,
This is just what I needed.

Appreciate the help.


Thanks

…….Cameron

From: IBM Mainframe Discussion List  On Behalf Of 
Lars Höglund
Sent: Monday, January 29, 2024 11:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Sv: How can I determine the User Name associated with the current 
Batch JOB RACF ID?

Something like this Code Extract: LINKAGE SECTION. 01 CB1. 05 PTR1 POINTER 
OCCURS 512. 01 CVT. 05 CVT1 POINTER OCCURS 512. 01 CB2. 05 PTR2 POINTER OCCURS 
256. . . . SET ADDRESS OF CB2 TO PTR1(4) MOVE CB2(1: 8) TO WS-BJOBNAMN SET 
ADDRESS OF CB2


Something like this



Code Extract:



LINKAGE SECTION.



01 CB1.

  05 PTR1 POINTER OCCURS 512.

01 CVT.

  05 CVT1 POINTER OCCURS 512.

01 CB2.

  05 PTR2 POINTER OCCURS 256.

.

.

.

SET ADDRESS OF CB2  TO PTR1(4)

MOVE CB2(1:8)TO WS-BJOBNAMN

SET ADDRESS OF CB2  TO PTR1(46)

MOVE CB2(361:8)  TO WS-BPGM

SET ADDRESS OF CB2  TO PTR2(80)

MOVE CB2(13:8) TO  BJOBNR

SET ADDRESS OF CB1  TO NULL

SET ADDRESS OF CB1  TO PTR1(138)

SET ADDRESS OF CB2  TO PTR1(28)

MOVE CB2(193:8) TO WS-BUSER







-Ursprungligt meddelande-

Från: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> För Cameron Conacher

Skickat: den 29 januari 2024 14:37

Till: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>

Ämne: How can I determine the User Name associated with the current Batch JOB 
RACF ID?



[Du f?r inte e-post ofta fr?n 
03cfc59146bb-dmarc-requ...@listserv.ua.edu<mailto:03cfc59146bb-dmarc-requ...@listserv.ua.edu>.
 L?s om varf?r det h?r ?r viktigt p? 
https://aka.ms/LearnAboutSenderIdentification<https://isolate.menlosecurity.com/1/3735928037/https:/aka.ms/LearnAboutSenderIdentification>
 ]



Good Morning,

I know I can do this in CICS, but I am digging around to see if this can be 
done in a batch COBOL program.

Basically, I just want to include Fred's Name in a report I generate, where 
Fred is the RACF ID associate with the currently executing Batch JOB. (a COBOL 
program).

I could write something to call out to CICS (EXCI maybe) to get a name.

But I wanted to know if there is anyway to do this by calling some routines 
from my Batch COBOL program.



I am assuming right now, it is not possible since I have come up empty so far.



Thanks





Cameron Conacher

Senior Engineer



American Express Canada Inc.

GCICS

2225 Sheppard Avenue East, Toronto, ON  M2J 5C2



cameron.conac...@aexp.com<mailto:cameron.conac...@aexp.com><mailto:cameron.conac...@aexp.com<mailto:cameron.conac...@aexp.com>>

Office: 1-437-836-5265

Mobile: 1-416-409-5147



https://amex.webex.com/join/cameron.conacher









American Express made the following annotations 
 This e-mail was sent to you by a 
representative of Amex Bank of Canada, P.O. Box 3204, Station "F", Toronto, ON, 
M1W 3W7, 
www.americanexpress.ca<https://isolate.menlosecurity.com/1/3735928037/http:/www.americanexpress.ca>.
 If you no longer wish to receive these e-mails, please notify the sender by 
reply e-mail.



This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.



American Express a fait les remarques suivantes Ce courriel vous a ?t? envoy? 
par un repr?sentant de la Banque Amex du Canada, C.P. 3204, succursale F, 
Toronto (Ontario) M1W 3W7, 
www.americanexpress.ca<https://isolate.menlosecurity.com/1/3735928037/http:/www.americanexpress.ca>.
 Si, par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en 
aviser les exp?diteurs par courriel.



Ce courriel est r?serv? au seul destinataire indiqu? et peut renfermer des 
renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire 
pr?vu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez re?u ce courriel par erreur, veuillez en aviser 
l'exp?diteur par courriel et d?truire imm?diatement le courriel et toute pi?ce 
jointe. Merci.



--

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



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with 
the message: INFO IBM-MAIN

How can I determine the User Name associated with the current Batch JOB RACF ID?

[Cameron Conacher]

Good Morning,
I know I can do this in CICS, but I am digging around to see if this can be 
done in a batch COBOL program.
Basically, I just want to include Fred's Name in a report I generate, where 
Fred is the RACF ID associate with the currently executing Batch JOB. (a COBOL 
program).
I could write something to call out to CICS (EXCI maybe) to get a name.
But I wanted to know if there is anyway to do this by calling some routines 
from my Batch COBOL program.

I am assuming right now, it is not possible since I have come up empty so far.

Thanks


Cameron Conacher
Senior Engineer

American Express Canada Inc.
GCICS
2225 Sheppard Avenue East, Toronto, ON  M2J 5C2

cameron.conac...@aexp.com<mailto:cameron.conac...@aexp.com>
Office: 1-437-836-5265
Mobile: 1-416-409-5147

https://amex.webex.com/join/cameron.conacher




American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a ?t? envoy? par un repr?sentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les exp?diteurs par courriel.

Ce courriel est r?serv? au seul destinataire indiqu? et peut renfermer des 
renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire 
pr?vu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez re?u ce courriel par erreur, veuillez en aviser 
l'exp?diteur par courriel et d?truire imm?diatement le courriel et toute pi?ce 
jointe. Merci.

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

Re: SORT Help with JFY and SQZ

[Cameron Conacher]

I believe that NULLOUT might help you here. (OPTION Statement)

Temporarily overrides the NULLOUT installation option, which specifies the 
action to be taken by DFSORT when there are no records for the SORTOUT data 
set, as indicated by an OUT count of 0 in message ICE054I RC0 specifies that 
DFSORT should issue message ICE173I, set a return code of 0, and continue 
processing when there are no records for the SORTOUT data set. RC4 specifies 
that DFSORT should issue message ICE173I, set a return code of 4, and continue 
processing when there are no records for the SORTOUT data set. RC16 specifies 
that DFSORT should issue message ICE206A, terminate, and give a return code of 
16 when there are no records for the SORTOUT data set.


Thanks

…….Cameron

From: IBM Mainframe Discussion List  On Behalf Of Don 
Johnson
Sent: Thursday, November 9, 2023 10:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SORT Help with JFY and SQZ

Hi Kolusu, I have one question about a situation that just came up. If the 
input file has no records to process, I would like to set a return code so I 
can bypass further processing. Is there a way that I can tweak this SORT input 
that you


Hi Kolusu, I have one question about a situation that just came up.



If the input file has no records to process, I would like to set a return code 
so I can bypass further processing. Is there a way that I can tweak this SORT 
input that you gave me to know if the SORTCMD1 file is empty, and set a CC for 
the step?



Don



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with 
the message: INFO IBM-MAIN


American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: Kinda fun

[Cameron Conacher]

I have very vague recollections of 51 column punch cards supporting bank charge 
cards in the mid seventies. (ChargeEx I think)
As a Waterloo coop student, I remember feeding boxes and boxes of these into a 
special card reader during overnight batch processing runs.
I think these were mostly from gas stations.


Thanks

...Cameron

From: IBM Mainframe Discussion List  On Behalf Of 
Schmitt, Michael
Sent: Wednesday, November 8, 2023 12:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Kinda fun

Are we violating the "no reminiscing" rule? What's the latest that people still 
used punched cards and/or paper tape? In the 80's I worked at a photofinishing 
plant that still used punched cards and paper tape as part of the processing 
work


Are we violating the "no reminiscing" rule?





What's the latest that people still used punched cards and/or paper tape?



In the 80's I worked at a photofinishing plant that still used punched cards 
and paper tape as part of the processing work flow. Punched cards were put in 
the processing envelope pouch, were updated at when the number of prints was 
determined, and fed the billing system at the end. Paper tape was used to 
control the which negatives were reprinted or enlarged.







--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with 
the message: INFO IBM-MAIN


American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a ?t? envoy? par un repr?sentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les exp?diteurs par courriel.

Ce courriel est r?serv? au seul destinataire indiqu? et peut renfermer des 
renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire 
pr?vu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez re?u ce courriel par erreur, veuillez en aviser 
l'exp?diteur par courriel et d?truire imm?diatement le courriel et toute pi?ce 
jointe. Merci.

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

Re: Kinda fun

[Cameron Conacher]

A hundred years ago, we had the IBM 1403 line printers.
When the box of paper ran out, the printer hood automatically raised and we 
would kick the empty box out and drop in a new full box.
Press the close hood button, and then the printer would continue printing.
Maybe the was a printer online button as well. I forget now.

Thanks

…….Cameron

From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Wednesday, November 8, 2023 10:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Kinda fun

I'm trying to remember, 'cause I was a $HASP operator, briefly, back in 
college. Let's see, that was a drum printer (not a chain). But why would the 
hood be pushed up when it ran out of paper? I can't picture what would be going 
on there. ---


I'm trying to remember, 'cause I was a $HASP operator, briefly, back in 
college.  Let's see, that was a drum printer (not a chain).  But why would the 
hood be pushed up when it ran out of paper?  I can't picture what would be 
going on there.



---

Bob Bridges, robhbrid...@gmail.com<mailto:robhbrid...@gmail.com>, cell 336 
382-7313



/* If you think health care is expensive now, wait until you see what it costs 
when it is free!  -P J O'Rourke */



-Original Message-

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Cameron Conacher

Sent: Wednesday, November 8, 2023 10:38



Anyone else recall….

Have the HASP operator read your JOB Deck, Walking over to the printer to 
collect your output Waiting for the output, and setting your card deck on the 
printer The printer running out of paper and the hood rises up Your card deck 
is spilled all over the floor



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with 
the message: INFO IBM-MAIN


American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: Kinda fun

[Cameron Conacher]

Anyone else recall….
Have the HASP operator read your JOB Deck,
Walking over to the printer to collect your output
Waiting for the output, and setting your card deck on the printer
The printer running out of paper and the hood rises up
Your card deck is spilled all over the floor


Thanks

…….Cameron

From: IBM Mainframe Discussion List  On Behalf Of 
Michael Oujesky
Sent: Wednesday, November 8, 2023 10:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Kinda fun

Sequence numbers could also be used for implementing a new release of vendor 
software that had been customized by in-house modifications. By comparing the 
old/new/in-house code you could identify which programs needed no conversion 
effort. 


Sequence numbers could also be used for implementing a new release of

vendor software that had been customized by in-house

modifications.  By comparing the old/new/in-house code you could

identify which programs needed no conversion effort. which programs

could be automatically adapted to the new release, which needed no

code changes, and those that required manual interpretation of the

releases changes versus in-house modifications.



separately. SYSLOG still has a 133 record length left over from the

360 days when the console was a 1050 typewriter using pin-fed

green-bar paper.  Though SAMPLIB(IEAMDBLG) can be modified to provide

SYSLOG from OPERLOG with a longer record length and do away with split lines.



Michael



At 08:38 AM 11/8/2023, Bob Bridges wrote:

>Ok, Shmuel, I'm curious.  Dropped decks are the only reason I ever heard,

>back when I was a $HASP operator.  What's the more important reason?

>

>(Mostly when customers brought huge decks of cards, two or three or four

>boxes sometimes, each card was a single row of a database, so the order

>didn't necessarily matter.  But with program code, sure.)

>

>---

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

>

>/* You know you've had too much coffee when

> Juan Valdez names his donkey after you.

> You've worn out the handle on your favorite coffee mug.

> Your eyes stay open when you sneeze. */

>

>-Original Message-

>From: IBM Mainframe Discussion List 
>mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of

>Seymour J Metz

>Sent: Wednesday, November 8, 2023 07:26

>

>People were using sequence numbers for editing before SPF. Dropped decks is

>but one of several reasons, and, IMHO, not the most important.

>

>--

>For IBM-MAIN subscribe / signoff / archive access instructions,

>send email to lists...@listserv.ua.edu 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


American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: TN3270, EBCDIC and ASCII

[Cameron Conacher]

Hello,
As far as I know, UTF-8 is not an option.
Full disclosure though, I have never tried.
DBCS (Double Byte Character Set) is an IBM construct.
The 3270 DataStream first see the x’0E’ which means Shift-Out of SBCS mode and 
into DBCS mode, and then we have a number of sixteen bit encoding units (double 
bytes) followed by an x’0F’, the Si – Shift In byte.
DBCS is required to support Japanese, Chinese, Korean and Vietnamese.
I have worked a fair bit with EBCDIC CodePage 930 (Japanese) and 937 
(Traditional Chinese).

Thanks

…….Cameron

From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Tuesday, October 10, 2023 1:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TN3270, EBCDIC and ASCII

On Tue, 10 Oct 2023 17: 06: 51 +, Cameron Conacher wrote: >Yes DBCS is 
available. >The block of DBCS data starts with a hex ‘0E’ and terminates with a 
hex ‘0F. > Which CCSID(s)? Which of these would be best for viewing a UTF-8 
file?


On Tue, 10 Oct 2023 17:06:51 +, Cameron Conacher wrote:



>Yes DBCS is available.

>The block of DBCS data starts with a hex ‘0E’ and terminates with a hex ‘0F.

>

Which CCSID(s)?



Which of these would be best for viewing a UTF-8 file?  (I'd hope for 1208.)



--

Thanks,

gil



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with 
the message: INFO IBM-MAIN


American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: TN3270, EBCDIC and ASCII

[Cameron Conacher]

Yes DBCS is available.
The block of DBCS data starts with a hex ‘0E’ and terminates with a hex ‘0F.


Thanks

…….Cameron

From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Tuesday, October 10, 2023 1:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TN3270, EBCDIC and ASCII

On Tue, 10 Oct 2023 12: 38: 13 -0400, Rick Troth wrote: > >TN3270 is an EBCDIC 
protocol. >When a TN3270 client program connects to a z/OS or z/VM or z/VSE or 
>z/TPF host (typically on TCP port 23) and negotiates for TN3270, >everything


On Tue, 10 Oct 2023 12:38:13 -0400, Rick Troth wrote:

>

>TN3270 is an EBCDIC protocol.

>When a TN3270 client program connects to a z/OS or z/VM or z/VSE or

>z/TPF host (typically on TCP port 23) and negotiates for TN3270,

>everything is EBCDIC after that. (Well ... everything except the

>signalling, of course. But the textual content is all EBCDIC.)

>

I believe TSO/ISPF issues a WSF Query at initial connection to determine

the terminal code page.  Edit/View senses the CCSID of the file (if available,

as set by chtag) and converts (using UnicodeServices?) those characters

available in the termina EBCDICl character set.



Does the 3270 data stream protocol support multi-byte characters?



--

gil



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with 
the message: INFO IBM-MAIN


American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: JAVA IDE

[Cameron Conacher]

Personally, I use Intellij.
I am happy with it.
I found many training videos on Pluralsite.
I have not used any other, so I cannot comment on the best or the most friendly.


Thanks

...Cameron

From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Wednesday, August 23, 2023 11:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JAVA IDE

I can believe that I'm asking this question. What is the best/most friendly 
JAVA IDE? Steve 
-- For 
IBM-MAIN subscribe / signoff / archive access instructions, send email to


I can believe that I'm asking this question.











What is the best/most friendly JAVA IDE?











Steve





--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with 
the message: INFO IBM-MAIN


American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a ?t? envoy? par un repr?sentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les exp?diteurs par courriel.

Ce courriel est r?serv? au seul destinataire indiqu? et peut renfermer des 
renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire 
pr?vu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez re?u ce courriel par erreur, veuillez en aviser 
l'exp?diteur par courriel et d?truire imm?diatement le courriel et toute pi?ce 
jointe. Merci.

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

Re: The ultimate (another one!) definition of mainframe

[Cameron Conacher]

Perhaps he was referring to OS/2?
Microsoft and IBM collaborated for a while.


Thanks

…….Cameron

From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Monday, August 14, 2023 6:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: The ultimate (another one!) definition of mainframe

I dunno. Jon Perryman said they had DOS and they let it go to Microsoft during 
other negotiations; I just took it from there. --- Bob Bridges, robhbridges@ 
gmail. com, cell 336 382-7313 /* You might be a physics major if, when your 
professor


I dunno.  Jon Perryman said they had DOS and they let it go to Microsoft during 
other negotiations; I just took it from there.



---

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



/* You might be a physics major if, when your professor asks you where your 
homework is, you claim accidentally to have determined its momentum so 
precisely that according to Heisenberg it could be anywhere in the universe. */



-Original Message-

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Grant 
Taylor

Sent: Monday, August 14, 2023 18:15



My hang up is that -- as I understand it -- DOS was /never/ IBM's to start with.



DOS was /Microsoft's/.



Or are you suggesting that IBM should have purchased exclusive rights to use / 
distribute / etc DOS from Microsoft?



--- On 8/14/23 3:16 PM, Bob Bridges wrote:

> I sort of agree, but I think underneath we still disagree.  I agree

> that IBM didn't think the PC software was worth developing.  And if

> they had held onto MS-DOS and approached its development in the same

> way that Microsoft did, sure, they'd probably be worth bazillions.



-Original Message-

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Jon 
Perryman

Sent: Monday, August 14, 2023 00:25



Stories vary widely but the most prevalent can be seen at 
https://youtu.be/Qc5khH5gllg?t=339
 which I positioned around the relevant time.



The story goes that MS-DOS did not exist at that time and IBM could have 
required exclusive rights but instead intentionally gave up its exclusive 
rights to MS-DOS for $0 during negotiations.



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with 
the message: INFO IBM-MAIN


American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: COBOL question

[Cameron Conacher]

Thanks.
Just to be clear.
I am running under EXPEDITER.
The program runs almost to completion.
The last two things I do:

  1.  If the Address is not NULL -> FREE
  2.  GOBACK.


Thanks

…….Cameron

From: IBM Mainframe Discussion List  On Behalf Of Joe 
Monk
Sent: Monday, April 10, 2023 9:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: COBOL question

A lot of times, U4038 is not enough region...

Joe

On Mon, Apr 10, 2023 at 6:15 AM Cameron Conacher <
03cfc59146bb-dmarc-requ...@listserv.ua.edu<mailto:03cfc59146bb-dmarc-requ...@listserv.ua.edu>>
 wrote:

> Good call 
>
> I ALLOCATE once.
> And just before GOBACK, I issue the FREE. Just one time.
> I am thinking it might be related to EXPEDITER.
>
> That is my current WAG.
>
>
> Thanks
>
> …….Cameron
>
> -Original Message-
> From: IBM Mainframe Discussion List 
> mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf
> Of Charles Mills
> Sent: Sunday, April 9, 2023 8:07 PM
> To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
> Subject: [External] Re: COBOL question
>
> I can't see your code of course but my WAG is a programmer logic error.
> (Sorry!) I am going to guess your logic is such that you try to free the
> same area twice or, less likely, corrupt your pointer.
>
> You say you check to see if it is null before freeing. Do you set it to
> NULL after freeing?
>
> Charles
>
> On Sun, 9 Apr 2023 23:01:05 +, Cameron Conacher <
> cameron.conac...@aexp.com<mailto:cameron.conac...@aexp.com>> wrote:
>
> >Thanks Bob,
> >No I initialize the Pointer to NULL, and then allocate. Successfully.
> >And then later I check to see it the pointer = NULL. If it is not NULL,
> then I do the FREE.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with the 
> message: INFO IBM-MAIN
> 
> American Express made the following annotations
> 
> This e-mail was sent to you by a representative of Amex Bank of Canada,
> P.O. Box 3204, Station "F", Toronto, ON, M1W 3W7, 
> www.americanexpress.ca<https://isolate.menlosecurity.com/1/3735928037/http:/www.americanexpress.ca>.
> If you no longer wish to receive these e-mails, please notify the sender by
> reply e-mail.
>
> This e-mail is solely for the intended recipient and may contain
> confidential or privileged information. If you are not the intended
> recipient, any disclosure, copying, use, or distribution of the information
> included in this e-mail is prohibited. If you have received this e-mail in
> error, please notify the sender by reply e-mail and immediately and
> permanently delete this e-mail and any attachments. Thank you.
>
> American Express a fait les remarques suivantes
> Ce courriel vous a été envoyé par un représentant de la Banque Amex du
> Canada, C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7,
> www.americanexpress.ca<https://isolate.menlosecurity.com/1/3735928037/http:/www.americanexpress.ca>.
>  Si, par la suite, vous ne souhaitez plus recevoir
> ces courriels, veuillez en aviser les expéditeurs par courriel.
>
> Ce courriel est réservé au seul destinataire indiqué et peut renfermer des
> renseignements confidentiels et privilégiés. Si vous n’êtes pas le
> destinataire prévu, toute divulgation, duplication, utilisation ou
> distribution du courriel est interdite. Si vous avez reçu ce courriel par
> erreur, veuillez en aviser l’expéditeur par courriel et détruire
> immédiatement le courriel et toute pièce jointe. Merci.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with 
> the message: INFO IBM-MAIN
>

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

American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, 

Re: COBOL question

[Cameron Conacher]

Good call 

I ALLOCATE once.
And just before GOBACK, I issue the FREE. Just one time.
I am thinking it might be related to EXPEDITER.

That is my current WAG.


Thanks

…….Cameron

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Sunday, April 9, 2023 8:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: COBOL question

I can't see your code of course but my WAG is a programmer logic error. 
(Sorry!) I am going to guess your logic is such that you try to free the same 
area twice or, less likely, corrupt your pointer.

You say you check to see if it is null before freeing. Do you set it to NULL 
after freeing?

Charles

On Sun, 9 Apr 2023 23:01:05 +, Cameron Conacher  
wrote:

>Thanks Bob,
>No I initialize the Pointer to NULL, and then allocate. Successfully.
>And then later I check to see it the pointer = NULL. If it is not NULL, then I 
>do the FREE.

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

American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: COBOL question

[Cameron Conacher]

Thanks Bob,
No I initialize the Pointer to NULL, and then allocate. Successfully.
And then later I check to see it the pointer = NULL. If it is not NULL, then I 
do the FREE.

Thanks

…….Cameron

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
T Roller
Sent: Saturday, April 8, 2023 8:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: COBOL question

Region card big enough? I’ve seen that abend via not enough memory.

Bob

Sent from Proton Mail for iOS

On Sat, Apr 8, 2023 at 8:17 PM, Charles Hardee  wrote:

> I have not seen this exactly like what you describe, but I do have
> some thoughts.
> The pointer you are using for the ALLOCATE, does it have a value
> clause, specifically VALUE NULL.
> If not, the pointer could have an unknown value that does not compare
> equal to NULL so you would attempt to FREE it.
>
> On Sat, Apr 8, 2023 at 6:05 PM Cameron Conacher  wrote:
>
>> Hello folks
>> I have written an IMS COBOL program. I have included a couple of
>> ALLOCATE statements.
>> At the end of processing I check my pointers and if they are not NULL
>> I try to FREE. This results in a U4038 abend. At least inside Expediter.
>> I have not used ALLOCATE/FREE before.
>> I am thinking it may be related to Expediter somehow.
>> I mean FREE is pretty darned straight forward.
>> At the moment I have commented out the statements. Memory should be
>> freed at the end of processing anyway, but good housekeeping is well good.
>> Has anyone seen this before?
>>
>> Thanks
>>
>> Sent from my iPhone
>> -
>> - For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu 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

American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

COBOL question

[Cameron Conacher]

Hello folks
I have written an IMS  COBOL program. I have included a couple of ALLOCATE 
statements.
At the end of processing I check my pointers and if they are not NULL I try to 
FREE. This results in a U4038 abend. At least inside Expediter.
I have not used ALLOCATE/FREE before. 
I am thinking it may be related to Expediter somehow.
I mean FREE is pretty darned straight forward.
At the moment I have commented out the statements. Memory should be freed at 
the end of processing anyway, but good housekeeping is well good.
Has anyone seen this before?

Thanks 

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

Anyone using z/OS Connect EE with IMS as a Provider?

[Cameron Conacher]

Hello,
I am not sure if this is the correct list to ask this.

Is anyone out there using z/OS Connect EE with IMS as a Service Provider?
We have been able to successfully process requests using EBCDIC CodePage 1047.
I am trying to make things work using CodePage UTF-16BE.

With IMS, the first two bytes of the Request Message are reserved for a BINARY 
LL data item.
The next two bytes are reserved for a BINARY ZZ data item.
The next eight bytes must contain the IMS Transaction Code.

If I want the request message to arrive in my IMS program encoded as UTF-16BE, 
I assume that the entire request message is encoded as UTF-16BE.
And, I believe this is wreaking havoc with the LLZZ and Transaction Code data 
items.

Has anyone managed to use CodePage UTF-16BE for these IMS Services in z/OS 
Connect?
Perhaps this just simply cannot be done?

Any thoughts would be appreciated.
Is there a z/OS Connect EE list? Or maybe an IMS list I should ask this in?

Thanks


Cameron Conacher
Senior Engineer

American Express Canada Inc.
GCICS
2225 Sheppard Avenue East, Toronto, ON  M2J 5C2

cameron.conac...@aexp.com<mailto:cameron.conac...@aexp.com>
Office: 1-437-836-5265
Mobile: 1-416-409-5147

https://amex.webex.com/join/cameron.conacher



American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a ?t? envoy? par un repr?sentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les exp?diteurs par courriel.

Ce courriel est r?serv? au seul destinataire indiqu? et peut renfermer des 
renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire 
pr?vu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez re?u ce courriel par erreur, veuillez en aviser 
l'exp?diteur par courriel et d?truire imm?diatement le courriel et toute pi?ce 
jointe. Merci.

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

Re: Stop the ragging on COBOL please [was: RE: ASM call by value]

[Cameron Conacher]

Good morning Peter,
SNOBOL??
Geeze that takes me way back.

I had a smile and had to call some old colleagues.

Thank you!

…….Cameron
OOO – March 28, 29, 30 and 31.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Monday, March 27, 2023 1:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Stop the ragging on COBOL please [was: RE: ASM call by 
value]

I am getting increasingly tired of snide or outright dismissive references to 
COBOL and by extension to COBOL programmers.

Programmers like me.

Yes, I am also well versed in HLASM, Rexx, awk and gawk, somewhat facile in 
SORT (at least as far as knowing and using JOIN's), SQL, JCL and various other 
z/OS utilities, MetalC, and lately python and bash scripting.  I even remember 
some of the PL/I and Fortran and Pascal I used in college and my early 
employment days.  I even remember some SNOBOL, which I actually got to use 
productively at a then-major NY bank very early in my career.

COBOL pays my bills and keeps my employer operating successfully and profitably.

COBOL does NOT rot the brain.  Alcohol and various other legal and illegal 
substances can, in fact, do that.  Intelligently devising business solutions to 
business problems in ANY computer language does NOT rot the brain.

It is not funny or acceptable to say so.  It never was.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Sunday, March 26, 2023 8:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value

On Sun, 26 Mar 2023 23:18:49 +, Frank Swarbrick wrote:



>In COBOL, for example, the following end up doing the same thing.
>
Do not use CO BOL as an exemplar of programming discipline.  Cobol rots the 
brain.

--

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

American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: One more REXX Question

[Cameron Conacher]

Thanks for the suggestion.
That did not work either,

…….Cameron

From: IBM Mainframe Discussion List  On Behalf Of 
Itschak Mugzach
Sent: Friday, March 3, 2023 11:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: One more REXX Question

So try isplog do ddname=syspront

בתאריך יום ו׳, 3 במרץ 2023 ב-17:29 מאת Cameron Conacher <
03cfc59146bb-dmarc-requ...@listserv.ua.edu<mailto:03cfc59146bb-dmarc-requ...@listserv.ua.edu>>:

> Hello Lance,
> I allocated a dataset and then included my new dataset name with the DD
> statement ISPLOG (DISP=MOD), but IEBCOPY still generates its own files and
> nothing is written to the ISPLOG file specified by the DD statement.
>
>
> Thanks
>
> …….Cameron
>
> From: IBM Mainframe Discussion List 
> mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf
> Of Lionel B. Dyck
> Sent: Friday, March 3, 2023 10:13 AM
> To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
> Subject: [External] Re: One more REXX Question
>
> Just alloc dd ISPLOG to the dataset you want with a DISP=MOD
>
> That should do it
>
>
> Lionel B. Dyck <><
> Website: 
> https://www.lbdsoftware.com<https://isolate.menlosecurity.com/1/3735928037/https:/www.lbdsoftware.com><
> https://isolate.menlosecurity.com/1/3735928037/https:/www.lbdsoftware.com>
> Github: 
> https://github.com/lbdyck<https://isolate.menlosecurity.com/1/3735928037/https:/github.com/lbdyck><
> https://isolate.menlosecurity.com/1/3735928037/https:/github.com/lbdyck>
>
> “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 
> mailto:IBM-MAIN@LISTSERV.UA.EDU> IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>>> On Behalf Of 
> Cameron Conacher
> Sent: Friday, March 3, 2023 9:04 AM
> To: 
> IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU><mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>>
> Subject: Re: One more REXX Question
>
> Hello Lionel,
> I am assuming that dataset LBDYCK.SPFLOG1.LIST contain the IEBCOPY output
> log information?
> And that this file was automatically allocated when your Batch JOB ran.
> (You did not pre-allocate before running the JOB).
>
> I want to try to use my own dataset name for this.
> Something like:
> CAMERON.SPFLOG1.LIST
> With DISP=MOD.
>
> But I do not understand how I can introduce this file so that when LMCOPY
> invokes IEBCOPY, IEBCOPY will write its log data there.
>
> I am running the REXX JOB in Batch (like you).
> I have tried assigning my own dataset names for SYSOUT, SYSPRINT and
> SYSTSPRT.
> But none catch any of the IEBCOPY output log data.
> And the other files are automatically generated for the JOB, every time I
> issue an LMCOPY command.
>
> I will try to find something in the Google Group for ISPF.
> If I find anything I will share.
>
> Thanks
>
> …….Cameron
>
> From: IBM Mainframe Discussion List 
> mailto:IBM-MAIN@LISTSERV.UA.EDU> IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>>> On Behalf Of 
> Lionel B. Dyck
> Sent: Friday, March 3, 2023 9:22 AM
> To: 
> IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU><mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>>
> Subject: [External] Re: One more REXX Question
>
> In my simple test I don't see any sysout.
>
> in = 'lbdyck.test.pds'
> out = 'lbdyck.test.pdse'
> Address ISPexec
> "lminit dataid(indd1) dataset('"in"')"
> "lminit dataid(outdd1) dataset('"out"')"
> "lmcopy fromid("indd1") todataid("outdd1")" ,
> "frommem(a*) replace"
> "lmcopy fromid("indd1") todataid("outdd1")" ,
> "frommem(b*) replace"
> "lmfree dataid("indd1")"
> "lmfree dataid("outdd1")"
>
>
> What I see in the batch execution is this:
>
> ispf cmd(%tlmcopy)
> LBDYCK.SPFLOG1.LIST has been kept.
> READY
>
> But no other sysout datasets.
>
> Lionel B. Dyck <><
> Website: 
> https://www.lbdsoftware.com<https://isolate.menlosecurity.com/1/3735928037/https:/www.lbdsoftware.com><
> https://isolate.menlosecurity.com/1/3735928037/https:/www.lbdsoftware.com
> ><
> https://isolate.menlosecurity.com/1/3735928037/https:/www.lbdsoftware.com>
> Github: 
> https://github.com/lbdyck<https://isolate.menlosecurity.com/1/3735928037/https:/github.com/lbdyck><
> https://isolate.menlosecurity.com/1/3735928037/https:/github.com/l

Re: One more REXX Question

[Cameron Conacher]

Much appreciated Lionel.
I will keep investigating and share whatever I may find.


Thanks

…….Cameron

From: IBM Mainframe Discussion List  On Behalf Of 
Lionel B. Dyck
Sent: Friday, March 3, 2023 10:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: One more REXX Question

I've no idea what to suggest on a resolution. If you have the ability, you 
could open a ticket with IBM to ask them. The ISPF support team is terrific.


Lionel B. Dyck <><
Website: 
https://www.lbdsoftware.com<https://isolate.menlosecurity.com/1/3735928037/https:/www.lbdsoftware.com>
Github: 
https://github.com/lbdyck<https://isolate.menlosecurity.com/1/3735928037/https:/github.com/lbdyck>

“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 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Cameron Conacher
Sent: Friday, March 3, 2023 9:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: One more REXX Question

Hello Lance,
I allocated a dataset and then included my new dataset name with the DD 
statement ISPLOG (DISP=MOD), but IEBCOPY still generates its own files and 
nothing is written to the ISPLOG file specified by the DD statement.


Thanks

…….Cameron

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Lionel 
B. Dyck
Sent: Friday, March 3, 2023 10:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: [External] Re: One more REXX Question

Just alloc dd ISPLOG to the dataset you want with a DISP=MOD

That should do it


Lionel B. Dyck <><
Website: 
https://www.lbdsoftware.com<https://isolate.menlosecurity.com/1/3735928037/https:/www.lbdsoftware.com><https://isolate.menlosecurity.com/1/3735928037/https:/www.lbdsoftware.com>
Github: 
https://github.com/lbdyck<https://isolate.menlosecurity.com/1/3735928037/https:/github.com/lbdyck><https://isolate.menlosecurity.com/1/3735928037/https:/github.com/lbdyck>

“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 
mailto:IBM-MAIN@LISTSERV.UA.EDU><mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>>>
 On Behalf Of Cameron Conacher
Sent: Friday, March 3, 2023 9:04 AM
To: 
IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU><mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>>
Subject: Re: One more REXX Question

Hello Lionel,
I am assuming that dataset LBDYCK.SPFLOG1.LIST contain the IEBCOPY output log 
information?
And that this file was automatically allocated when your Batch JOB ran. (You 
did not pre-allocate before running the JOB).

I want to try to use my own dataset name for this.
Something like:
CAMERON.SPFLOG1.LIST
With DISP=MOD.

But I do not understand how I can introduce this file so that when LMCOPY 
invokes IEBCOPY, IEBCOPY will write its log data there.

I am running the REXX JOB in Batch (like you).
I have tried assigning my own dataset names for SYSOUT, SYSPRINT and SYSTSPRT.
But none catch any of the IEBCOPY output log data.
And the other files are automatically generated for the JOB, every time I issue 
an LMCOPY command.

I will try to find something in the Google Group for ISPF.
If I find anything I will share.

Thanks

…….Cameron

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU><mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>>>
 On Behalf Of Lionel B. Dyck
Sent: Friday, March 3, 2023 9:22 AM
To: 
IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU><mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>>
Subject: [External] Re: One more REXX Question

In my simple test I don't see any sysout.

in = 'lbdyck.test.pds'
out = 'lbdyck.test.pdse'
Address ISPexec
"lminit dataid(indd1) dataset('"in"')"
"lminit dataid(outdd1) dataset('"out"')"
"lmcopy fromid("indd1") todataid("outdd1")" ,
"frommem(a*) replace"
"lmcopy fromid("indd1") todataid("outdd1")" ,
"frommem(b*) replace"
"lmfree dataid("indd1")"
"lmfree dataid("outdd1")"


What I see in the batch execution is this:

ispf cmd(%tlmcopy)
LBDYCK.SPFLOG1.LIST has been kept.
READY

But no other sysout datasets.

Lionel B. Dyck <><
Website: 
https://www.lbdsoftware.com<https://isolate.menlosecurity.com/1/3735928037/https:/www.lbdsoftware.com><https://isolate.menlosecurity.com/1/3735928037/https:/www.lbdsoftware.com><https://isolate.menlosecurity.com/1/3735928037/https:/www.lbdsoftware.com>
Github: 
https://g

Re: One more REXX Question

[Cameron Conacher]

Hello Lance,
I allocated a dataset and then included my new dataset name with the DD 
statement ISPLOG (DISP=MOD), but IEBCOPY still generates its own files and 
nothing is written to the ISPLOG file specified by the DD statement.


Thanks

…….Cameron

From: IBM Mainframe Discussion List  On Behalf Of 
Lionel B. Dyck
Sent: Friday, March 3, 2023 10:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: One more REXX Question

Just alloc dd ISPLOG to the dataset you want with a DISP=MOD

That should do it


Lionel B. Dyck <><
Website: 
https://www.lbdsoftware.com<https://isolate.menlosecurity.com/1/3735928037/https:/www.lbdsoftware.com>
Github: 
https://github.com/lbdyck<https://isolate.menlosecurity.com/1/3735928037/https:/github.com/lbdyck>

“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 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Cameron Conacher
Sent: Friday, March 3, 2023 9:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: One more REXX Question

Hello Lionel,
I am assuming that dataset LBDYCK.SPFLOG1.LIST contain the IEBCOPY output log 
information?
And that this file was automatically allocated when your Batch JOB ran. (You 
did not pre-allocate before running the JOB).

I want to try to use my own dataset name for this.
Something like:
CAMERON.SPFLOG1.LIST
With DISP=MOD.

But I do not understand how I can introduce this file so that when LMCOPY 
invokes IEBCOPY, IEBCOPY will write its log data there.

I am running the REXX JOB in Batch (like you).
I have tried assigning my own dataset names for SYSOUT, SYSPRINT and SYSTSPRT.
But none catch any of the IEBCOPY output log data.
And the other files are automatically generated for the JOB, every time I issue 
an LMCOPY command.

I will try to find something in the Google Group for ISPF.
If I find anything I will share.

Thanks

…….Cameron

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Lionel 
B. Dyck
Sent: Friday, March 3, 2023 9:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: [External] Re: One more REXX Question

In my simple test I don't see any sysout.

in = 'lbdyck.test.pds'
out = 'lbdyck.test.pdse'
Address ISPexec
"lminit dataid(indd1) dataset('"in"')"
"lminit dataid(outdd1) dataset('"out"')"
"lmcopy fromid("indd1") todataid("outdd1")" ,
"frommem(a*) replace"
"lmcopy fromid("indd1") todataid("outdd1")" ,
"frommem(b*) replace"
"lmfree dataid("indd1")"
"lmfree dataid("outdd1")"


What I see in the batch execution is this:

ispf cmd(%tlmcopy)
LBDYCK.SPFLOG1.LIST has been kept.
READY

But no other sysout datasets.

Lionel B. Dyck <><
Website: 
https://www.lbdsoftware.com<https://isolate.menlosecurity.com/1/3735928037/https:/www.lbdsoftware.com><https://isolate.menlosecurity.com/1/3735928037/https:/www.lbdsoftware.com>
Github: 
https://github.com/lbdyck<https://isolate.menlosecurity.com/1/3735928037/https:/github.com/lbdyck><https://isolate.menlosecurity.com/1/3735928037/https:/github.com/lbdyck>

“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 
mailto:IBM-MAIN@LISTSERV.UA.EDU><mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>>>
 On Behalf Of Paul Gilmartin
Sent: Friday, March 3, 2023 8:10 AM
To: 
IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU><mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>>
Subject: Re: One more REXX Question

On Fri, 3 Mar 2023 09:40:18 +0200, ITschak Mugzach wrote:

>Allocate syspront as MOD instead of share and all outputs will be
>written to same file (do not free and allocate syspront every call)
>
Does the description of LMCOPY in the ISPF Services Guide,SC19-3626-50, mention 
the use of SYSPRONT or any similar DDNAME? If not, thd documentation is 
defective/


>בתאריך יום ו׳, 3 במרץ 2023 ב-5:02 מאת Paul Gilmartin:
>
>> This is less a REXX question than an ISPF question, and might get
>> more focused replies in ISPF-LIST.
>>
>> On Thu, 2 Mar 2023 23:56:52 +, Cameron Conacher wrote:
>> > ...
>> >When the LMCOPY runs, it writes some IEBCOPY processing messages to
>> >a
>> generated file name, which has a high level qualifier of the RACF ID
>> under which the JOB runs.
>> >If two members are copied, LMCOPY is executed twice, and two IEBCOPY
>> files are generated. if 100 membe

Re: One more REXX Question

[Cameron Conacher]

Hello Lionel,
I am assuming that dataset LBDYCK.SPFLOG1.LIST contain the IEBCOPY output log 
information?
And that this file was automatically allocated when your Batch JOB ran. (You 
did not pre-allocate before running the JOB).

I want to try to use my own dataset name for this.
Something like:
CAMERON.SPFLOG1.LIST
With DISP=MOD.

But I do not understand how I can introduce this file so that when LMCOPY 
invokes IEBCOPY, IEBCOPY will write its log data there.

I am running the REXX JOB in Batch (like you).
I have tried assigning my own dataset names for SYSOUT, SYSPRINT and SYSTSPRT.
But none catch any of the IEBCOPY output log data.
And the other files are automatically generated for the JOB, every time I issue 
an LMCOPY command.

I will try to find something in the Google Group for ISPF.
If I find anything I will share.

Thanks

…….Cameron

From: IBM Mainframe Discussion List  On Behalf Of 
Lionel B. Dyck
Sent: Friday, March 3, 2023 9:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: One more REXX Question

In my simple test I don't see any sysout.

in = 'lbdyck.test.pds'
out = 'lbdyck.test.pdse'
Address ISPexec
"lminit dataid(indd1) dataset('"in"')"
"lminit dataid(outdd1) dataset('"out"')"
"lmcopy fromid("indd1") todataid("outdd1")" ,
"frommem(a*) replace"
"lmcopy fromid("indd1") todataid("outdd1")" ,
"frommem(b*) replace"
"lmfree dataid("indd1")"
"lmfree dataid("outdd1")"


What I see in the batch execution is this:

ispf cmd(%tlmcopy)
LBDYCK.SPFLOG1.LIST has been kept.
READY

But no other sysout datasets.

Lionel B. Dyck <><
Website: 
https://www.lbdsoftware.com<https://isolate.menlosecurity.com/1/3735928037/https:/www.lbdsoftware.com>
Github: 
https://github.com/lbdyck<https://isolate.menlosecurity.com/1/3735928037/https:/github.com/lbdyck>

“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 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Paul 
Gilmartin
Sent: Friday, March 3, 2023 8:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: One more REXX Question

On Fri, 3 Mar 2023 09:40:18 +0200, ITschak Mugzach wrote:

>Allocate syspront as MOD instead of share and all outputs will be
>written to same file (do not free and allocate syspront every call)
>
Does the description of LMCOPY in the ISPF Services Guide,SC19-3626-50, mention 
the use of SYSPRONT or any similar DDNAME? If not, thd documentation is 
defective/


>בתאריך יום ו׳, 3 במרץ 2023 ב-5:02 מאת Paul Gilmartin:
>
>> This is less a REXX question than an ISPF question, and might get
>> more focused replies in ISPF-LIST.
>>
>> On Thu, 2 Mar 2023 23:56:52 +, Cameron Conacher wrote:
>> > ...
>> >When the LMCOPY runs, it writes some IEBCOPY processing messages to
>> >a
>> generated file name, which has a high level qualifier of the RACF ID
>> under which the JOB runs.
>> >If two members are copied, LMCOPY is executed twice, and two IEBCOPY
>> files are generated. if 100 members are copied I get 100 IEBCOPY
>> files generated.
>> >
>> I'm slightly surprised. But I've used LMCOPY only to copy a PS data
>> set to a PDS mdmber.
>> IEBCOPY isn't needed (or allowed) for that operation.
>>
>> Likewise, IEBCOPY shouldn't be necessary to copy PDS member to PDS member.
>>
>> But does LMCOPY replicate the directory user info? The Ref. doesn't say.
>>
>> Are the members program objects?
>>
>> >My question is this, can I direct all of the IEBCOPY output
>> >(assuming it
>> is SYSPRINT) directed to one single output file?
>> >So, instead of seeing 100 individual IEBCOPY, I only get one single
>> consolidated file with a name of my choosing?

--
gil

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

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

American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify th

One more REXX Question

[Cameron Conacher]

Hello everyone,
I am using REXX (specifically LMCOPY) to copy PDS members from one library to 
another.
Everything is working just fine. Everything copies as I expect it to.

When the LMCOPY runs, it writes some IEBCOPY processing messages to a generated 
file name, which has a high level qualifier of the RACF ID under which the JOB 
runs.
If two members are copied, LMCOPY is executed twice, and two IEBCOPY files are 
generated. if 100 members are copied I get 100 IEBCOPY files generated.

My question is  this, can I direct all of the IEBCOPY output (assuming it is 
SYSPRINT) directed to one single output file?
So, instead of seeing 100 individual IEBCOPY, I only get one single 
consolidated file with a name of my choosing?

IEBCOPY appears to run under the covers for LMCOPY.
I cannot see anywhere that LMCOPY accepts a parameter indicating where to send 
the IEBCOPY output.

To help clarify things, I can use LMCOPY to copy PDS.LIBRAY1(Member1) to 
PDS.LIBRAY2(Member1) without any issues.
But under the covers LMCOPY seems to run IEBCOPY and I see generated output 
files for IEBCOPY like RACFID.SPF101.IEBCOPY.

Can I tell LMCOPY to inform IEBCOPY to use MYNAME.IEBCOPY.SYSPRINT instead of 
the generated name?

Thanks


Cameron Conacher
Senior Engineer

American Express Canada Inc.
GCICS
2225 Sheppard Avenue East, Toronto, ON  M2J 5C2

cameron.conac...@aexp.com<mailto:cameron.conac...@aexp.com>
Office: 1-437-836-5265
Mobile: 1-416-409-5147

https://amex.webex.com/join/cameron.conacher



American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a ?t? envoy? par un repr?sentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les exp?diteurs par courriel.

Ce courriel est r?serv? au seul destinataire indiqu? et peut renfermer des 
renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire 
pr?vu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez re?u ce courriel par erreur, veuillez en aviser 
l'exp?diteur par courriel et d?truire imm?diatement le courriel et toute pi?ce 
jointe. Merci.

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

Re: Having a little difficulty with a REXX command LMOPEN

[Cameron Conacher]

Nice.
Thank you.

Sent from my iPhone

> On Feb 5, 2023, at 5:12 PM, Lionel B. Dyck  wrote:
> 
> If you want a tool to copy members from one library to another based on 
> differences, then check out my ZSYNC tool. It can compare two PDS/PDSE 
> libraries (doesn't understand member generations using either ISPF Statistics 
> or member contents.
> 
> You can find it at https://github.com/lbdyck/zsync or file 314 at 
> www.cbttape.org
> 
> 
> Lionel B. Dyck <><
> Website: https://www.lbdsoftware.com
> Github: https://github.com/lbdyck
> 
> “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 
> Cameron Conacher
> Sent: Sunday, February 5, 2023 3:59 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Having a little difficulty with a REXX command LMOPEN
> 
> Here is my DO/END Loop.
> I am copying members from a previous Backup Library, back into my execution 
> Library, using an input list to derive a MEMBER Name (I have named this 
> string variable rComp.) I do an LMINIT of the backup Library And then I do an 
> LMOPEN of the backup Library I do an LMINIT of the target execution Library
> 
> The I do an LMMLIST to find my backup Library Member named rComp If the 
> LMMLIST fails (can’t find the Member name in my Backup Library) I write an 
> error message and issue an ITERATE.
> Before issuing the ITERATE, I SHOULD have included code for the LMMLIST 
> option(free), LMCLOSE and LMFREE.
> Normally, I do these things, just before the END of the DO/END block. But, 
> ITERATE takes me out of the loop and starts again at the top.
> 
> Also, one should “normally” check the return code from an LMOPEN.
> My stumbling block was that I could see in the trace output, that the LMOPEN 
> failed with a RC=8, and I did not know why it really failed.
> 
> Do ip = 1 to icomp.0
>   /* Parse record to various fields */
>   rNlib = strip(substr(icomp.ip, 69, 44))
>   rNbkp = strip(substr(icomp.ip, 114, 44))
>   rComp = strip(substr(icomp.ip, 1, 8))
>   rCont = strip(substr(icomp.ip, 14, 10))
>   rPath = strip(substr(icomp.ip, 21, 2))
>   rptRsn = '!!! Component not moved !!!'
>   /* Fully qualified DSN names with quotes */
>   fqNbkp = "'"||rNbkp||"'"
>   fqNlib = "'"||rNlib||"'"
> 
>   /* LMINIT the from & to PDS */
>   Address ISPEXEC
>   "LMINIT DATAID(Nbkp) DATASET("fqNbkp") ENQ(shrw)"
>   If rc /= 0 Then Do
>  errMsg1 = ' Unable to access Production PDS. Check if the library
>  errMsg2 = ' 'fqNbkp' exists/Contact Programmer. RC for LMINIT 'rc
>  exRC = rc
>  signal evac
>   End
> 
>   "LMOPEN Dataid("Nbkp")"
> 
>   "LMINIT DATAID(Nlib) DATASET("fqNlib") ENQ(shrw)"
>   If rc > 0 Then Do
>  errMsg1 = ' Unable to access Production PDS. Check if the library
>  errMsg2 = ' 'fqNlib' exists/Contact Programmer. '
>  exRC = rc
>  signal evac
>   End
> 
>   eoPDS = 'N'
>   "LMMLIST Dataid("Nbkp") OPTION(LIST) STATS(NO)",
>   "MEMBER(rComp)"
>   If rc >= 4 Then Do
>  errMsg1 = ' Member 'rComp' not found in Backup library.'
>  errMsg2 = ' Data was not replaced.'
>  say errMsg1
>  say errMsg2
>  /*  This is where my error is. I need to do the LMCLOSE/LMFREE work here, 
> before I ITERATE. */
> 
>  Iterate
> 
>  /*  signal evac */
>   End
> 
>   Else Do
>  replFl = 'REPLACE'
>  "LMMOVE FROMID("Nbkp") TODATAID("Nlib")",
>  "FROMMEM("rComp") "replFl
>  If rc /= 0 Then Do
> errMsg1 = "LMMOVE error for "rComp
> errMsg2 = "Return code was "rc
> exRC = rc
> signal evac
>  End
>  Else Do
> rptRsn = 'Move from N-Backup library complete'
>  End
>   End
> 
>   call buildrpt
> 
>   "LMMLIST Dataid("Nbkp") OPTION(free)"
>   "LMCLOSE Dataid("Nlib")"
>   "LMFREE Dataid("Nbkp")"
>   "LMFREE Dataid("Nlib")"
> End
> 
> Thanks
> 
> …….Cameron
> 
> From: IBM Mainframe Discussion List  On Behalf Of 
> Hobart Spitz
> Sent: Sunday, February 5, 2023 4:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [External] Re: Having a little difficulty with a REXX command LMOPEN
> 
> I have a few thoughts. I still have to guess because you didn't include all 
> of the relevant code, and your colors d

Re: Having a little difficulty with a REXX command LMOPEN

[Cameron Conacher]

Here is my DO/END Loop.
I am copying members from a previous Backup Library, back into my execution 
Library, using an input list to derive a MEMBER Name (I have named this string 
variable rComp.)
I do an LMINIT of the backup Library
And then I do an LMOPEN of the backup Library
I do an LMINIT of the target execution Library

The I do an LMMLIST to find my backup Library Member named rComp
If the LMMLIST fails (can’t find the Member name in my Backup Library) I write 
an error message and issue an ITERATE.
Before issuing the ITERATE, I SHOULD have included code for the LMMLIST 
option(free), LMCLOSE and LMFREE.
Normally, I do these things, just before the END of the DO/END block. But, 
ITERATE takes me out of the loop and starts again at the top.

Also, one should “normally” check the return code from an LMOPEN.
My stumbling block was that I could see in the trace output, that the LMOPEN 
failed with a RC=8, and I did not know why it really failed.

Do ip = 1 to icomp.0
   /* Parse record to various fields */
   rNlib = strip(substr(icomp.ip, 69, 44))
   rNbkp = strip(substr(icomp.ip, 114, 44))
   rComp = strip(substr(icomp.ip, 1, 8))
   rCont = strip(substr(icomp.ip, 14, 10))
   rPath = strip(substr(icomp.ip, 21, 2))
   rptRsn = '!!! Component not moved !!!'
   /* Fully qualified DSN names with quotes */
   fqNbkp = "'"||rNbkp||"'"
   fqNlib = "'"||rNlib||"'"

   /* LMINIT the from & to PDS */
   Address ISPEXEC
   "LMINIT DATAID(Nbkp) DATASET("fqNbkp") ENQ(shrw)"
   If rc /= 0 Then Do
  errMsg1 = ' Unable to access Production PDS. Check if the library
  errMsg2 = ' 'fqNbkp' exists/Contact Programmer. RC for LMINIT 'rc
  exRC = rc
  signal evac
   End

   "LMOPEN Dataid("Nbkp")"

   "LMINIT DATAID(Nlib) DATASET("fqNlib") ENQ(shrw)"
   If rc > 0 Then Do
  errMsg1 = ' Unable to access Production PDS. Check if the library
  errMsg2 = ' 'fqNlib' exists/Contact Programmer. '
  exRC = rc
  signal evac
   End

   eoPDS = 'N'
   "LMMLIST Dataid("Nbkp") OPTION(LIST) STATS(NO)",
   "MEMBER(rComp)"
   If rc >= 4 Then Do
  errMsg1 = ' Member 'rComp' not found in Backup library.'
  errMsg2 = ' Data was not replaced.'
  say errMsg1
  say errMsg2
  /*  This is where my error is. I need to do the LMCLOSE/LMFREE work here, 
before I ITERATE. */

  Iterate

  /*  signal evac */
   End

   Else Do
  replFl = 'REPLACE'
  "LMMOVE FROMID("Nbkp") TODATAID("Nlib")",
  "FROMMEM("rComp") "replFl
  If rc /= 0 Then Do
 errMsg1 = "LMMOVE error for "rComp
 errMsg2 = "Return code was "rc
 exRC = rc
 signal evac
  End
  Else Do
 rptRsn = 'Move from N-Backup library complete'
  End
   End

   call buildrpt

   "LMMLIST Dataid("Nbkp") OPTION(free)"
   "LMCLOSE Dataid("Nlib")"
   "LMFREE Dataid("Nbkp")"
   "LMFREE Dataid("Nlib")"
End

Thanks

…….Cameron

From: IBM Mainframe Discussion List  On Behalf Of 
Hobart Spitz
Sent: Sunday, February 5, 2023 4:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Having a little difficulty with a REXX command LMOPEN

I have a few thoughts. I still have to guess because you didn't include
all of the relevant code, and your colors didn't come through.

- Are you missing "LMCLOSE Dataid("Nbkp")". This might cause an
exhaustion of LMOPEN resources. It would be my guess for the best
candidate solution.
- Adding TRACE COM, temporarily, might give you (and us) more
information. Please send the last screen or two of trace output, including
the terminating error message (s).
- As you know, zerrsm and zerrlm give crucial information. Please share
those values.
- It might be worth looking into your log (option 7.5); you must turn on
the ISPF log. (I pity the genius who does anything with ISPEXEC/ISREDIT
commands but doesn't have their log turned on.)
- It's not clear, but you might have been using SIGNAL EVAC as a GO TO.
It is not! This form of SIGNAL unwinds any structures within the current
procedure before transferring control. Any active DO loops are removed!
This might be the reason it appeared that SIGNAL EVAC causes a
problem, when everything was working as designed. LEAVE might be what you
need. It ends an inner loop, but lets an outer one continue.
- I have never heard of a "VSAM library", but you may be referring to
something other than what I'm interpreting the comment to mean.

Other than those, I think you have most of the elements correct and in
place, so I think you are close.

OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) o

Re: Having a little difficulty with a REXX command LMOPEN

[Cameron Conacher]

Yep, I am doing LMFREE and LMCLOSE, but I had introduced an error when I 
included an INTERATE command in the middle of a DO/END and so in a specific 
situation, the LMFREE/LMCLOSE would not get executed.
And then in the subsequent iteration, I would see the LMOPEN error.

I got a return code of 8, but did not see any additional information and I 
completely forgot (old age?) I should be dumping out zerrsm and zerrlm.
I should ALWAYS execute the REXX statements in green, but when I arrive in the 
yellow code, I skip over the LMFEE/LMCLOSE which causes grief with the 
subsequent iterations.


   /* Copy all members from VSAM library. No exceptions here */
   "LMMLIST Dataid("Nbkp") OPTION(LIST) STATS(NO)",
   "MEMBER(rComp)"
   If rc >= 4 Then Do
  errMsg1 = ' Member 'rComp' not found in Backup library.'
  errMsg2 = ' Data was not replaced.'
  say errMsg1
  say errMsg2
  Iterate* This causes an issue for subsequent iterations 
of the DO/END
  /*  signal evac */
   End
   Else Do
  replFl = 'REPLACE'
  "LMMOVE FROMID("Nbkp") TODATAID("Nlib")",
  "FROMMEM("rComp") "replFl
  If rc /= 0 Then Do
 errMsg1 = "LMMOVE error for "rComp
 errMsg2 = "Return code was "rc
 exRC = rc
 signal evac
  End
  Else Do
 rptRsn = 'Move from N-Backup library complete'
  End
   End
   call buildrpt
   "LMMLIST Dataid("Nbkp") OPTION(free)"
   "LMCLOSE Dataid("Nlib")"
   "LMFREE Dataid("Nbkp")"
   "LMFREE Dataid("Nlib")"
End



Thanks

…….Cameron

From: IBM Mainframe Discussion List  On Behalf Of 
Hobart Spitz
Sent: Sunday, February 5, 2023 1:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Having a little difficulty with a REXX command LMOPEN

Are you doing LMFREE, on the dataid from LMINIT, when you are finished with
each library?
It sounds like you are exceeding resources for LMINITs.

I don't think FREE/CLOSE is needed. LMINIT and LMFREE are faster, more
reliable and easier to use.

It also sounds like you are not getting the return code back so you can
display zerrsm and zerrlm. (Unless you did this and I missed it.) You may
need to issue SIGNAL OFF ERROR, and/or ADDRESS ISPEXEC "CONTROL ERRORS
RETURN". Otherwise your program won't be able to report what happened.

Please study and understand Lionell's example. Your outer (library) loop
should include all of those elements.

We still need to see your code as written; I'm just guessing from your
description. There could be something you are doing that I have not
considered.


OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)? Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Sun, Feb 5, 2023 at 11:51 AM Cameron Conacher <
03cfc59146bb-dmarc-requ...@listserv.ua.edu<mailto:03cfc59146bb-dmarc-requ...@listserv.ua.edu>>
 wrote:

> Thanks a ton everyone.
> Just a dumb User issue here (me).
>
> I have a DO loop, and at the bottom of the loop I manage the cleanup
> (FREE/CLOSE)
> However, inside the loop I had some code where I would report an
> encountered error, and then issue ITERATE to work with the next input
> library member.
> In this situation I never actually got to the bottom of the Loop and I
> never issued the FREE/CLOSE.
> The next time I tried an LMOPEN on the same library, it failed.
>
> Appreciate the helpful information.
> I did not remember I could dump the zerrsm and zerrlm to get additional
> information.
>
> Thanks
>
> ...Cameron
>
> From: IBM Mainframe Discussion List 
> mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf
> Of Lionel B. Dyck
> Sent: Friday, February 3, 2023 8:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
> Subject: [External] Re: Having a little difficulty with a REXX command
> LMOPEN
>
> Here is a sample that I wrote awhile ago to better understand how lmcopy
> works - hope this helps - no lmopen required.
>
> /* --- REXX --- *
> * test code for lmcopy *
> *  */
> in = 'hlq.test.pds'
> out = 'hlq.test.pdse'
> Address ISPexec
> "lminit dataid(indd1) dataset('"in"')"
> "lminit dataid(outdd1) dataset('"out"')"
> "lmcopy fromid("indd1") todataid("outdd1")" ,
> "frommem(a*) replace"
> "lmcopy fromid("indd1") todataid("outdd1")" ,
> &q

Re: Having a little difficulty with a REXX command LMOPEN

[Cameron Conacher]

Thanks a ton everyone.
Just a dumb User issue here (me).

I have a DO loop, and at the bottom of the loop I manage the cleanup 
(FREE/CLOSE)
However, inside the loop I had some code where I would report an encountered 
error, and then issue ITERATE to work with the next input library member.
In this situation I never actually got to the bottom of the Loop and I never 
issued the FREE/CLOSE.
The next time I tried an LMOPEN on the same library, it failed.

Appreciate the helpful information.
I did not remember I could dump the zerrsm and zerrlm to get additional 
information.

Thanks

...Cameron

From: IBM Mainframe Discussion List  On Behalf Of 
Lionel B. Dyck
Sent: Friday, February 3, 2023 8:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Having a little difficulty with a REXX command LMOPEN

Here is a sample that I wrote awhile ago to better understand how lmcopy
works - hope this helps - no lmopen required.

/* --- REXX --- *
* test code for lmcopy *
*  */
in = 'hlq.test.pds'
out = 'hlq.test.pdse'
Address ISPexec
"lminit dataid(indd1) dataset('"in"')"
"lminit dataid(outdd1) dataset('"out"')"
"lmcopy fromid("indd1") todataid("outdd1")" ,
"frommem(a*) replace"
"lmcopy fromid("indd1") todataid("outdd1")" ,
"frommem(b*) replace"
"lmfree dataid("indd1")"
"lmfree dataid("outdd1")"


Lionel B. Dyck <><
Website: 
https://www.lbdsoftware.com<https://isolate.menlosecurity.com/1/3735928037/https:/www.lbdsoftware.com>
Github: 
https://github.com/lbdyck<https://isolate.menlosecurity.com/1/3735928037/https:/github.com/lbdyck>

"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 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of
Cameron Conacher
Sent: Friday, February 3, 2023 7:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Having a little difficulty with a REXX command LMOPEN

Good Morning,
I have a small REXX which essentially copies members of one PDSE to another.

It iterates over members of the first PDSE and copies the members to the
second PDSE.

After about eighty members are copied, my LMOPEN fails with a return code of
8.
I checked the manual and a return code of 8 from an LMOPEN means "The
Dataset cannot be opened."
8
Data set could not be opened.


Is there somewhere I can see a bit more detail. Why the dataset could not be
opened?
I see nothing in the JES Log.

Any thoughts appreciated.

Thanks


Cameron Conacher
Senior Engineer

American Express Canada Inc.
GCICS
2225 Sheppard Avenue East, Toronto, ON M2J 5C2

cameron.conac...@aexp.com<mailto:cameron.conac...@aexp.com><mailto:cameron.conac...@aexp.com<mailto:cameron.conac...@aexp.com>>
Office: 1-437-836-5265
Mobile: 1-416-409-5147

https://amex.webex.com/join/cameron.conacher

Note: I will be away from the office on PTO Friday February 3, 2023


American Express made the following annotations
 This e-mail was sent to you by a
representative of Amex Bank of Canada, P.O. Box 3204, Station "F", Toronto,
ON, M1W 3W7, 
www.americanexpress.ca<https://isolate.menlosecurity.com/1/3735928037/http:/www.americanexpress.ca>.
 If you no longer wish to receive these
e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain
confidential or privileged information. If you are not the intended
recipient, any disclosure, copying, use, or distribution of the information
included in this e-mail is prohibited. If you have received this e-mail in
error, please notify the sender by reply e-mail and immediately and
permanently delete this e-mail and any attachments. Thank you.

American Express a fait les remarques suivantes Ce courriel vous a ?t?
envoy? par un repr?sentant de la Banque Amex du Canada, C.P. 3204,
succursale F, Toronto (Ontario) M1W 3W7, 
www.americanexpress.ca<https://isolate.menlosecurity.com/1/3735928037/http:/www.americanexpress.ca>.
 Si, par la
suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser les
exp?diteurs par courriel.

Ce courriel est r?serv? au seul destinataire indiqu? et peut renfermer des
renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le
destinataire pr?vu, toute divulgation, duplication, utilisation ou
distribution du courriel est interdite. Si vous avez re?u ce courriel par
erreur, veuillez en aviser l'exp?diteur par courriel et d?truire
imm?diatement le courriel et toute pi?ce jointe. Merci.

--
For IBM-MAIN subscribe / signoff / archive access 

Having a little difficulty with a REXX command LMOPEN

[Cameron Conacher]

Good Morning,
I have a small REXX which essentially copies members of one PDSE to another.

It iterates over members of the first PDSE and copies the members to the second 
PDSE.

After about eighty members are copied, my LMOPEN fails with a return code of 8.
I checked the manual and a return code of 8 from an LMOPEN means "The Dataset 
cannot be opened."
 8
Data set could not be opened.


Is there somewhere I can see a bit more detail. Why the dataset could not be 
opened?
I see nothing in the JES Log.

Any thoughts appreciated.

Thanks


Cameron Conacher
Senior Engineer

American Express Canada Inc.
GCICS
2225 Sheppard Avenue East, Toronto, ON  M2J 5C2

cameron.conac...@aexp.com<mailto:cameron.conac...@aexp.com>
Office: 1-437-836-5265
Mobile: 1-416-409-5147

https://amex.webex.com/join/cameron.conacher

Note: I will be away from the office on PTO Friday February 3, 2023


American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a ?t? envoy? par un repr?sentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les exp?diteurs par courriel.

Ce courriel est r?serv? au seul destinataire indiqu? et peut renfermer des 
renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire 
pr?vu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez re?u ce courriel par erreur, veuillez en aviser 
l'exp?diteur par courriel et d?truire imm?diatement le courriel et toute pi?ce 
jointe. Merci.

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

Re: REXX Question

[Cameron Conacher]

Hello Bob,
I probably SHOULD probably read what you have and try to understand things.
If for no other reason than understanding.
I am certain I will see this again.

Thanks

…….Cameron

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Tuesday, January 17, 2023 4:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: REXX Question

If it works, great.  But since I was all primed to offer another kind of 
solution, I'm remembering an explanation I sent once about how to ask RACF (and 
I take it from your symptoms that you are running RACF) whether you have READ 
access to a particular dataset.  It seems to me it can be adapted to check 
whether you have UPDATE access.  It's more complicated than the below, but if 
you're interested

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

/* When I was ten, I read fairy tales in secret and would have been ashamed if 
I had been found doing so. Now that I am fifty I read them openly. When I 
became a man I put away childish things, including the fear of childishness and 
the desire to be very grown up.  -C.S. Lewis */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Cameron Conacher
Sent: Tuesday, January 17, 2023 15:41

Thank you.
This looks like just what I needed.
Appreciate the assistance.

---
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Tuesday, January 17, 2023 3:03 PM

Did you try CONTROL ERRORS RETURN?


From: Cameron Conacher
Sent: Tuesday, January 17, 2023 2:48 PM

I have some REXX statements that use LMCOPY to copy members from one library to 
another.
This is pretty straight forward stuff.
Recently, I ran into a situation where I was not authorized to access the 
output library.
And when the REXX ran, it ABENDed with a 913 error message.
My REXX checks the return code value from the LMCOPY, but apparently, the 
LMCOPY does not return. I can't seem to trap the not authorized error, and 
generate a polite message for the JOB.

After issuing the LMCOPY command, I check, and if the return code is not one of 
0, 8, or 12 I generate an error message.
On the other hand
if it is zero I generate a success message if it is 8 I generate a success 
message if it is 12 I generate a message indicating I did not replace the 
member in the target library because the member already existed and the REPLACE 
flag was not set.

The other return codes documented for LMCOPY are
16 = TRUNCATION Error
20 = Sever Error; unable to continue.

I was kind of expecting to see the LMCOPY return set as 20.
Is there something I can set to trap the 913 (Not Authorized error) ?
I can live with what I have. I was just looking to polish things up a little 
bit.

I wanted to send out a message that literally says "You do not have the 
authority to access Library . Please reach out to the Security team at... 
and have them authorize your RACF ID. Then restart this JOB at step If you 
have additional questions, please see ."

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

American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: REXX Question

[Cameron Conacher]

Thank you.
This looks like just what I needed.
Appreciate the assistance.

Thanks

...Cameron

From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Tuesday, January 17, 2023 3:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: REXX Question

Did you try CONTROL ERRORS RETURN?


From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of 
Cameron Conacher 
<03cfc59146bb-dmarc-requ...@listserv.ua.edu<mailto:03cfc59146bb-dmarc-requ...@listserv.ua.edu>>
Sent: Tuesday, January 17, 2023 2:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: REXX Question

Hello folks,
I hope this is not a silly question.
I have some REXX statements that use LMCOPY to copy members from one library to 
another.
This is pretty straight forward stuff.
Recently, I ran into a situation where I was not authorized to access the 
output library.
And when the REXX ran, it ABENDed with a 913 error message.
My REXX checks the return code value from the LMCOPY, but apparently, the 
LMCOPY does not return. I can't seem to trap the not authorized error, and 
generate a polite message for the JOB.

After issuing the LMCOPY command, I check, and if the return code is not one of 
0, 8, or 12 I generate an error message.
On the other hand
if it is zero I generate a success message
if it is 8 I generate a success message
if it is 12 I generate a message indicating I did not replace the member in the 
target library because the member already existed and the REPLACE flag was not 
set.

The other return codes documented for LMCOPY are
16 = TRUNCATION Error
20 = Sever Error; unable to continue.

I was kind of expecting to see the LMCOPY return set as 20.
Is there something I can set to trap the 913 (Not Authorized error) ?
I can live with what I have. I was just looking to polish things up a little 
bit.

I wanted to send out a message that literally says "You do not have the 
authority to access Library . Please reach out to the Security team at... 
and have them authorize your RACF ID. Then restart this JOB at step If you 
have additional questions, please see ."

Or know that it is just not possible/reasonable to attempt to trap the error.

Thanks


Cameron Conacher
Senior Engineer

American Express Canada Inc.
GCICS
2225 Sheppard Avenue East, Toronto, ON M2J 5C2

cameron.conac...@aexp.com<mailto:cameron.conac...@aexp.com><mailto:cameron.conac...@aexp.com<mailto:cameron.conac...@aexp.com>>
Office: 1-437-836-5265
Mobile: 1-416-409-5147

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Famex.webex.com%2Fjoin%2Fcameron.conacher=05%7C01%7Csmetz3%40gmu.edu%7Cde15c95b27b348cba8be08daf8c3cea0%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638095817113716787%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=hBFyD3LJjmBm%2FnJeRGRL7Y9iArO12Q6WrKOHWQAA%2BtY%3D=0<https://isolate.menlosecurity.com/1/3735928037/https:/nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Famex.webex.com%2Fjoin%2Fcameron.conacher=05%7C01%7Csmetz3%40gmu.edu%7Cde15c95b27b348cba8be08daf8c3cea0%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638095817113716787%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=hBFyD3LJjmBm%2FnJeRGRL7Y9iArO12Q6WrKOHWQAA%2BtY%3D=0>


American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, 
http://secure-web.cisco.com/1ZxhzI5uLo43smfRqmfJL3HBskUBpKOJa3Qcn2n9RumUh1HClQH2zfhZx_LVjPxydiGXOs0mNI3vZlAPeG3_jtkfz7djJuLX8HHU-GxXIHOuJ57gnTs6yn9rscZDqaZgXGRAuyYgIpQpzHGb-OOESPjhd92iW6ZNl1CyU9OxYwees8Py00f1KtTVokIqV1I79xORACPu6MpguSlk57x9qHa4Ckf8sPA5SaFyS6kId6bYuYoHfZKuyI5Bu4ArJIBhavhRi_tIcvkpmdxol6rdkrFpI8Nh8FR8MDWQgppxBp7o-QecTui2QHAO6xUI-SdnOYPq_aV5_UNfV-bTyzifWlbiXrCAqkwKonT50TQnk3A7DNWMp0S9WjCmBC0QtO6Wnz1ufJK93XZIP91TfW9plDqdq3t5VkIH0d8dwgWT3KqAWoCZCFVN9611_hBhx-ktv/http%3A%2F%2Fwww.americanexpress.ca<https://isolate.menlosecurity.com/1/3735928037/http:/secure-web.cisco.com/1ZxhzI5uLo43smfRqmfJL3HBskUBpKOJa3Qcn2n9RumUh1HClQH2zfhZx_LVjPxydiGXOs0mNI3vZlAPeG3_jtkfz7djJuLX8HHU-GxXIHOuJ57gnTs6yn9rscZDqaZgXGRAuyYgIpQpzHGb-OOESPjhd92iW6ZNl1CyU9OxYwees8Py00f1KtTVokIqV1I79xORACPu6MpguSlk57x9qHa4Ckf8sPA5SaFyS6kId6bYuYoHfZKuyI5Bu4ArJIBhavhRi_tIcvkpmdxol6rdkrFpI8Nh8FR8MDWQgppxBp7o-QecTui2QHAO6xUI-SdnOYPq_aV5_UNfV-bTyzifWlbiXrCAqkwKonT50TQnk3A7DNWMp0S9WjCmBC0QtO6Wnz1ufJK93XZIP91TfW9plDqdq3t5VkIH0d8dwgWT3KqAWoCZCFVN9611_hBhx-ktv/http%3A%2F%2Fwww.americanexpress.ca>
 If you no longer wish to receive these e-mails, please notify the sender by 
reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged informa

REXX Question

[Cameron Conacher]

Hello folks,
I hope this is not a silly question.
I have some REXX statements that use LMCOPY to copy members from one library to 
another.
This is pretty straight forward stuff.
Recently, I ran into a situation where I was not authorized to access the 
output library.
And when the REXX ran, it ABENDed with a 913 error message.
My REXX checks the return code value from the LMCOPY, but apparently, the 
LMCOPY does not return. I can't seem to trap the not authorized error, and 
generate a polite message for the JOB.

After issuing the LMCOPY command, I check, and if the return code is not one of 
0, 8, or 12 I generate an error message.
On the other hand
if it is zero I generate a success message
if it is 8 I generate a success message
if it is 12 I generate a message indicating I did not replace the member in the 
target library because the member already existed and the REPLACE flag was not 
set.

The other return codes documented for LMCOPY are
16 = TRUNCATION Error
20 = Sever Error; unable to continue.

I was kind of expecting to see the LMCOPY return set as 20.
Is there something I can set to trap the 913 (Not Authorized error) ?
I can live with what I have. I was just looking to polish things up a little 
bit.

I wanted to send out a message that literally says "You do not have the 
authority to access Library . Please reach out to the Security team at... 
and have them authorize your RACF ID. Then restart this JOB at step If you 
have additional questions, please see ."

Or know that it is just not possible/reasonable to attempt to trap the error.

Thanks


Cameron Conacher
Senior Engineer

American Express Canada Inc.
GCICS
2225 Sheppard Avenue East, Toronto, ON  M2J 5C2

cameron.conac...@aexp.com<mailto:cameron.conac...@aexp.com>
Office: 1-437-836-5265
Mobile: 1-416-409-5147

https://amex.webex.com/join/cameron.conacher


American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a ?t? envoy? par un repr?sentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les exp?diteurs par courriel.

Ce courriel est r?serv? au seul destinataire indiqu? et peut renfermer des 
renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire 
pr?vu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez re?u ce courriel par erreur, veuillez en aviser 
l'exp?diteur par courriel et d?truire imm?diatement le courriel et toute pi?ce 
jointe. Merci.

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

Re: Is DEBE still alive?

[Cameron Conacher]

About 100 years ago we had DEBE (Does Everything But Eat) and DNBE (Does 
Nothing But Eat)
A long time ago

Thanks

…….Cameron

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Johnson
Sent: Tuesday, September 27, 2022 9:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Is DEBE still alive?

Does Everything But Eat is what we called it.


Sent from Yahoo Mail for iPhone


On Tuesday, September 27, 2022, 9:36 AM, ITschak Mugzach  
wrote:

I don't have this module installed, but wonder if it will work on a Z/OS system 
if it was installed.



ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring for 
z/OS, x/Linux & IBM I **| z/VM coming soon  *

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu 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

American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: ELAX DRAWDOWN??

[Cameron Conacher]

IBM's Elastic Storage Server (ESS) and Max Drawdown (MDD) ?? Maybe?

…….Cameron

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Wednesday, August 31, 2022 10:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] ELAX DRAWDOWN??

Any one heard of this or what it is?

I got asked about it and I've never heard of it, and it is supposedly an IBM 
product and I can't find doc on it in an IBM site.

Regards,
Steve Thompson

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

American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: SORT question: Extract varying length string adding suffix after string?

[Cameron Conacher]

If I understand things correctly, you could use Squeeze (SQZ) to eliminate the 
embedded blanks.
Something like SQZ=(SHIFT=LEFT).
Maybe you will need another SORT step to squeeze the entire record?

Thanks,

...Cameron

From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter x23353
Sent: Saturday, April 2, 2022 3:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] SORT question: Extract varying length string adding suffix 
after string?

I have a use case to extract a varying length string where I need to add both 
prefix and suffix constants to the selected string.

The SORT PARSE operand doesn't seem to do the trick because the FIXLEN 
parameter to PARSE is required and the selected strings will be blank-padded to 
the FIXLEN length.

Is there any way to use SORT for this job or should I be looking at another 
utility? I know I can also do the job using a simple awk script, but I wanted 
to see if SORT could do the job too.

The strings at issue happen to be classic dataset names, 
PDS.NAME(MBRNAME)
 format. Input and output files are both RECFM=VB.

Example input:

SOME OTHER DATA HERE:DATA.NAME1(MBR001)
SOME OTHER DATA HERE:OTHER.DATA.NAME2(MBR002)
SOME OTHER DATA 
HERE:REALLY.LONG.PDS.DATASET.NAME(MBR003)

Sort control cards that I tried:

SORT FIELDS=(26,52,CH,A)
SUM FIELDS=NONE
OUTREC PARSE=(%00=(ABSPOS=26,ENDBEFR=BLANKS,FIXLEN=52)),
BUILD=(1,4,C'PREFIX DATA:',%00,C':SUFFIX DATA')

Output looks like this:

PREFIX DATA:DATA.NAME1(MBR001) :SUFFIX DATA
PREFIX DATA:OTHER.DATA.NAME2(MBR002) :SUFFIX DATA
PREFIX 
DATA:REALLY.LONG.PDS.DATASET.NAME(MBR003)
 :SUFFIX DATA

Desired output would look like this:

PREFIX DATA:DATA.NAME1(MBR001):SUFFIX DATA
PREFIX DATA:OTHER.DATA.NAME2(MBR002):SUFFIX DATA
PREFIX 
DATA:REALLY.LONG.PDS.DATASET.NAME(MBR003):SUFFIX
 DATA

TIA for any advice you can offer.

Peter
--


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

American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a ?t? envoy? par un repr?sentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les exp?diteurs par courriel.

Ce courriel est r?serv? au seul destinataire indiqu? et peut renfermer des 
renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire 
pr?vu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez re?u ce courriel par erreur, veuillez en aviser 
l'exp?diteur par courriel et d?truire imm?diatement le courriel et toute pi?ce 
jointe. Merci.

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

Re: z/OS ISPF Panel to include System Name

[Cameron Conacher]

Can I somehow add this to the ISPF startup command?

ISPF SYSNAME ON? --> Nope
ISPF ‘SYSNAME ON’ --> Nope

ISPF
SYSNAME ON --> O.K.


Thanks,

…….Cameron





From: IBM Mainframe Discussion List  On Behalf Of 
PINION, RICHARD W.
Sent: Thursday, February 24, 2022 3:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: z/OS ISPF Panel to include System Name

I learn something new everyday!


-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Lionel 
B. Dyck
Sent: Thursday, February 24, 2022 3:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS ISPF Panel to include System Name

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

You can also enter SYSNAME ON or OFF on the ISPF command line.


Lionel B. Dyck <><
Website: 
https://urldefense.com/v3/__https://www.lbdsoftware.com__;!!HnnddUIWDII9UQ!CiLcdnxKLTlSnZjQB79gJrhYAyLYgbEmnJOzog98V6nAcmlOQ5lSnRPSCNpNc6fGfvE$
Github: 
https://urldefense.com/v3/__https://github.com/lbdyck__;!!HnnddUIWDII9UQ!CiLcdnxKLTlSnZjQB79gJrhYAyLYgbEmnJOzog98V6nAcmlOQ5lSnRPSCNpNY4DT71M$

“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 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
PINION, RICHARD W.
Sent: Thursday, February 24, 2022 02:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS ISPF Panel to include System Name

You can edit the source of the panel. You need to figure out where the panel is 
coming from, in regards to your ISPF allocations (CLIST/REXX, logon proc)

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Jasi 
Grewal
Sent: Thursday, February 24, 2022 3:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: z/OS ISPF Panel to include System Name

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

Hi,
Is there a way to replace the ispf panelid name on top left screen of zOS ISPF 
Panel with System name.
- Is there a tool to include system name on top left or on right of the screen 
when you are on primary panel or under any panels in zOS ISPF.
- I understand that you can have it on primary panel but am more interested in 
other ispf panels.
Any information would be appreciated.Thank You in advance,Regards,Jasi Grewal.

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

American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail 

Re: Holy Moly ...

[Cameron Conacher]

That is inspiring.
I like what I do.
I hope to work as long as I want to.
I sometimes wonder what I could possibly be doing, if I was not in IT.
I think I would become a waiter. I would sit all day and wait…..

Thanks,

…….Cameron





From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Monday, February 14, 2022 4:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Holy Moly ...

On 15/2/22 4:53 am, Richards, Robert B. (CTR) wrote:
>> some of our guys will go on until 70
> Some of us are past that! (Going on for 80!!!) 

You're not the only one! One of our testers is 81 and still delivering
exceptional results. He has no plans to retire and we don't want him to.


> -Original Message-
> From: IBM Mainframe Discussion List 
> mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
> David Crayford
> Sent: Monday, February 14, 2022 3:26 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Holy Moly ...
>
> You make some good points in this post. None of us on this forum are getting 
> any younger and IBM-MAIN doesn't seem to attract young people who prefer 
> platforms like Stack Overflow or Slack workspaces. It may be an unpopular 
> opinion, but it's important to concentrate on millenials now. A large 
> percentage of developers in my location are in their 60s and close to 
> retirement. It's not easy to train young people to back-fill as our legacy 
> products are written in HLASM and require deep technical knowledge of MVS 
> subsystems. It's optimistic to speculate that it will take 5 years to bring 
> somebody up to speed when it's probably more like 10. We hope that now we are 
> all working from home that some of our guys will go on until 70. We are also 
> modernizing our products and for that we need young guys. While it's 
> certainly not impossible, it's certainly very difficult to retrain a HLASM 
> programmer to Java, Python, Javascript etc. It's not because they're not 
> smart enough, they just don't want to.
>
> On 14/2/22 10:10 pm, René Jansen wrote:
>> It is not so much about capitalism as it is about respectful use of language 
>> to describe groups of people. 
>> https://features.propublica.org/ibm/ibm-age-discrimination-american-workers/
>>  
>> >
>>  shows that the problem is not exactly new but that the outrage then was 
>> limited to terms like ‘grey hairs and old heads’. The following part is 
>> interesting:
>>
>> "By the time IBM’s current CEO, Virginia “Ginni” Rometty, took over in 2012, 
>> the company had shifted its personnel focus to millennials.
>> Rometty launched a major overhaul that aimed to make IBM a major player in 
>> the emerging technologies of cloud services, big data analytics, mobile, 
>> security and social media, or what came to be known inside as CAMS.
>> At the same time, she sought to sharply increase hiring of people born after 
>> 1980.
>> “CAMS are driven by Millennial Traits,” declared a slide presentation for an 
>> invitation-only IBM event in New York in December 2014. Not only were 
>> millennials in sync with the new technologies, but they were also attuned to 
>> the collaborative, consensus-driven modes of work these technologies 
>> demanded, company researchers said they’d discovered. Millennials “are not 
>> likely to make decisions in isolation,” the presentation said, but instead 
>> “depend on analytic technologies to help them.”
>> By contrast, people 50 or over are “more dubious” of analytics, “place less 
>> stock in the advantages data offers,” and are less “motivated to consult 
>> their colleagues or get their buy in … It’s Baby Boomers who are the 
>> outliers.”
>> The message was clear. To succeed at the new technologies, the company must, 
>> in the words of the presentation, “become one with the Millennial mindset.” 
>> Similar language found its way into a variety of IBM presentations in 
>> subsequent years.”
>>
>> A company’s workforce needs to be sustained by its earnings - this was even 
>> true in socialism and that is what ended it in eastern europe - you cannot 
>> sell your grain and eat it - and IBM needed to focus on its earnings. Where 
>> earlier cash flow and earnings were based on scientific research (much of it 
>> publicly financed at universities) and government/defence contracts 
>> (publicly financed) and an exemplary execution of those contracts with 
>> military precision (which led to the tendency of dictating customers what 
>> they needed in a command and control like structure) lead them to neglect 
>> the market and think they could fill in the parts they missed (mini 
>> computers and personal computers (the original PC, 

Re: Having some challenges with a SORT Utility

[Cameron Conacher]

Thanks Bob.

…….Cameron





From: IBM Mainframe Discussion List  On Behalf Of 
Robert S. Hansel (RSH)
Sent: Thursday, January 20, 2022 8:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Having some challenges with a SORT Utility

Hi Cameron,

Generating and processing RACF LISTUSER data is extremely inefficient and is 
not a sanctioned application programming interface. I recommend you look into 
processing a RACF database unload file generated by the IRRDBU00 utility, with 
which you could probably use SORT's JOINKEY to do much of what you are trying 
to do with less code. Most installations generate an IRRDBU00 unload every day, 
so there is apt to be one readily available for you to use. Better still, I 
believe your firm has IBM's RACF add-on product zSecure. It might very well be 
able to generate the report you are looking for without having to write a 
single line of code. I suggest you contact your RACF Admin team to ask them 
about the availability of an IRRDBU00 unload and zSecure.

Regards, Bob

Robert S. Hansel 35 years of RACF Experience
Lead RACF Specialist 2021 #IBMChampion
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel<https://isolate.menlosecurity.com/1/3735928037/http:/www.linkedin.com/in/roberthansel>
www.twitter.com/RSH_RACF<https://isolate.menlosecurity.com/1/3735928037/http:/www.twitter.com/RSH_RACF>
www.rshconsulting.com<https://isolate.menlosecurity.com/1/3735928037/http:/www.rshconsulting.com>
---
Upcoming RSH RACF Training - WebEx
- RACF Level I Administration - APR 4-8, 2022
- RACF Level II Administration - MAR 7-11, 2022
- RACF Level III Admin, Audit, & Compliance - FEB 14-18, 2022
- RACF - Securing z/OS UNIX - JAN 24-28, 2022
---

-Original Message-
Date: Wed, 19 Jan 2022 22:23:51 +
From: Cameron Conacher 
mailto:cameron.conac...@aexp.com>>
Subject: Having some challenges with a SORT Utility

Hello folks,
Hopefully someone can point me in a correct direction.
I can do this in a different manner, but I am stubborn.

I have crafted a little sort utility to read a file and then to grab data from 
a couple of records and include the data with subsequent records.

So, I have a record identifying a dataset name. (One record)
Then some number of records later, I will have a record identifying an Owner 
group. (One record)
And then after a few records I will have some other record with names. (A 
number of records- hundreds or perhaps only one)

DataSet Name Record
Noise records
Owner Group record
Noise records
Name Record
Name Record
.
.
.
.
Noise records
DataSet Name Record

And so on.

My sort eliminate the noise records, and then I try to carry the dataset name 
and the owner group forward to add it to the name records for final output.

When I run my utility, I get the very first name record (with the dataset and 
owner information).
The subsequent name records do not have the additional data on output because 
somehow I have messed up.


Could someone have a peek at my sort control statement and suggest either a fix 
or tell me DON'T DO IT.

Thanks.

And here are my sort control statements.
**
* *
* SCAN THROUGH THE INPUT FILE AND GENERATE AN OUTPUT DETAIL *
* FILE COMBINING DATA FROM MULTIPLE RECORDS. *
* *
* WE ONLY WANT THE RECORDS CONTAINING ONE OF: *
* 'LISTDSD DATASET(' IN POSITION 002 *
* ' 00 ' IN POSITION 002 *
* ' ALTER ' IN POISITON 011 *
* 'CONTROL' IN POISITON 011 *
* ' READ ' IN POISITON 011 *
* 'UPDATE ' IN POISITON 011 *
* *
**

INCLUDE COND=(01,20,SS,EQ,C'LISTDSD DATASET', * ONLY LISTDSD RECS
OR,
01,20,SS,EQ,C' 00 ', * OWNER RECORDS
OR,
10,20,SS,EQ,C' ALTER ', * ALTER ACCESS
OR,
10,20,SS,EQ,C'CONTROL ', * CONTROL ACCESS
OR,
10,20,SS,EQ,C' READ ', * READ ACCESS
OR,
10,20,SS,EQ,C'UPDATE ') * UPDATE ACCESS


* *
* PARSE THE INPUT RECORDS LOOKING FOR THE LITERALS REPRESENTING *
* THE LISTDSD, OWNER AND RACF ID/ACCESS (DIFFERENT RECORDS) *
* USING A GROUP OF THREE RECORDS (1=LISTDSD 2=OWNER 3=RACF ID) *
* OVERLAY THE WORK AREA DATA IN 101-132 WITH: *
* 101-104 = 'RACF' *
* 105-150 = 45 CHARACTERS FOR LISTDSD NAME *
* 151-158 = OWNER NAME *
* 159-166 = RACF ID *
* 167 175 = RACF ID ACCESS ALLOWED *
* 181-184 = FOUR DIGIT RECORD NUMBER *
* 185-186 = TWO DIGIT GROUP ID NUMBER *
* 187-189 = THREE DIGIT SEQUENCE NUMBER *
* 190-190 = RECORD TYPE; 1=LISTDSD 2=OWNER 3=RACF ID/ACCESS *
* 191-193 = '123' RECORD TYPES *
* 201-245 = 45 CHARACTERS FOR LISTDSD NAME *
* 246-253 = EIGHT CHANRATER OWNER NAME *
* 254-261 = EIGHT CHANRATER RACF ID *
* 262-268 = SEVEN CHARACTER RACF ACCESS AVAILABLE *
* *
INREC IFTHEN=(WHEN=INIT,
BUILD=(001,080, * CURRENT RECORD
101:C'RACF', * LITERAL
105:C'LISTDSD', * LISTDSD DATASET
151:C'OWNER', * OWN

Re: Having some challenges with a SORT Utility

[Cameron Conacher]

Thank you!

...Cameron





From: IBM Mainframe Discussion List  On Behalf Of Sri 
h Kolusu
Sent: Wednesday, January 19, 2022 8:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Having some challenges with a SORT Utility

Cameron,

Here is a simple version of DFSORT which will produce the results you are
looking for


//STEP0100 EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTIN DD DISP=SHR,DSN=Your.LISTDSD.output
//SORTOUT DD SYSOUT=*
//SYSIN DD *
OPTION COPY
*** Get listdsd dataset name using parse ***
INREC IFTHEN=(WHEN=INIT,
PARSE=(%01=(STARTAFT=C'LISTDSD DATASET(''',
ENDBEFR=C''')',
FIXLEN=44)),
OVERLAY=(081:%01)), # DSN NAME

*** Get owner name using parse ***
IFTHEN=(WHEN=INIT,
PARSE=(%02=(STARTAFT=C' 00 ',
ENDBEFR=C' ',
FIXLEN=08)),
OVERLAY=(130:%02)), # OWNER

*** If dataset name > ' ' push it for all records ***
IFTHEN=(WHEN=GROUP,
BEGIN=(081,1,CH,GT,C' '),
PUSH=(081:081,44)),

*** If owner name > ' ' push it for all records ***
IFTHEN=(WHEN=GROUP,
BEGIN=(130,1,CH,GT,C' '),
PUSH=(130:130,08)),

*** Group the ids and access ***
IFTHEN=(WHEN=GROUP,
BEGIN=(001,16,CH,EQ,C' ID ACCESS'),
END=(001,16,CH,EQ,C' '),
PUSH=(140:SEQ=3))

OUTFIL REMOVECC,
** Pick if the group for id access sequence > 2 as
** the first 2 lines are headers AND
** ID in position 1 should be greater than ' ' ***
INCLUDE=(140,3,ZD,GT,2,AND,
001,8,CH,GT,C' '),
BUILD=(C'RACF ',
081,44,X, $ dataset name
130,08,X, $ Owner
001,08,X, $ ID
011,08,JFY=(SHIFT=LEFT), $ Access type
80:X),
HEADER1=(06:'LIST DATASET NAME',
51:'OWNER',
60:' ID ',
69:'ACCESS',/,
06:44'-',51:08'-',60:08'-',69:08'-')

/*


This will Produce a report like this

LIST DATASET NAME OWNER ID ACCESS
  

RACF 
HLQ.SLQ.TLQ.NAME
 OWNER1 USERID01 ALTER
RACF 
HLQ.SLQ.TLQ.NAME
 OWNER1 USERID02 UPDATE
...


Further if you have any questions please let me know

Thanks,
Kolusu
DFSORT Development
IBM Corporation

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

American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a ?t? envoy? par un repr?sentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les exp?diteurs par courriel.

Ce courriel est r?serv? au seul destinataire indiqu? et peut renfermer des 
renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire 
pr?vu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez re?u ce courriel par erreur, veuillez en aviser 
l'exp?diteur par courriel et d?truire imm?diatement le courriel et toute pi?ce 
jointe. Merci.

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

Re: Having some challenges with a SORT Utility

[Cameron Conacher]

Massimo,
Thank you,
I modified the control statements to allow up to 500 records in a group.
And now things seem to be perfect.
I had tried setting the 500 value on the last group, thinking “I have less than 
five hundred of these”, rather than at the higher level to indicate there could 
be five hundred items in a group.

Anyway, I am back in business.

Thanks again.

…….Cameron





From: IBM Mainframe Discussion List  On Behalf Of 
Massimo Biancucci
Sent: Wednesday, January 19, 2022 6:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Having some challenges with a SORT Utility

Cameron,

sorry for not fully understanding. For me it's not so simple to "see your
dataset".
I'm wondering why you specified the RECORDS= on WHEN=GROUP.
If I well understand the manual:
"
If RECORDS is specified with BEGIN or KEYBEGIN, up to n records starting
with the begin
record belong to a group.
"
this could mean the dataset infos will populate a maximum of 3 records
after it triggers.
How does TRACEIT look like ?

Hope this helps.
Max


Il giorno mer 19 gen 2022 alle ore 23:24 Cameron Conacher <
03cfc59146bb-dmarc-requ...@listserv.ua.edu<mailto:03cfc59146bb-dmarc-requ...@listserv.ua.edu>>
 ha scritto:

> Hello folks,
> Hopefully someone can point me in a correct direction.
> I can do this in a different manner, but I am stubborn.
>
> I have crafted a little sort utility to read a file and then to grab data
> from a couple of records and include the data with subsequent records.
>
> So, I have a record identifying a dataset name. (One record)
> Then some number of records later, I will have a record identifying an
> Owner group. (One record)
> And then after a few records I will have some other record with names. (A
> number of records- hundreds or perhaps only one)
>
> DataSet Name Record
> Noise records
> Owner Group record
> Noise records
> Name Record
> Name Record
> .
> .
> .
> .
> Noise records
> DataSet Name Record
>
> And so on.
>
> My sort eliminate the noise records, and then I try to carry the dataset
> name and the owner group forward to add it to the name records for final
> output.
>
> When I run my utility, I get the very first name record (with the dataset
> and owner information).
> The subsequent name records do not have the additional data on output
> because somehow I have messed up.
>
>
> Could someone have a peek at my sort control statement and suggest either
> a fix or tell me DON'T DO IT.
>
> Thanks.
>
> And here are my sort control statements.
> **
> * *
> * SCAN THROUGH THE INPUT FILE AND GENERATE AN OUTPUT DETAIL *
> * FILE COMBINING DATA FROM MULTIPLE RECORDS. *
> * *
> * WE ONLY WANT THE RECORDS CONTAINING ONE OF: *
> * 'LISTDSD DATASET(' IN POSITION 002 *
> * ' 00 ' IN POSITION 002 *
> * ' ALTER ' IN POISITON 011 *
> * 'CONTROL' IN POISITON 011 *
> * ' READ ' IN POISITON 011 *
> * 'UPDATE ' IN POISITON 011 *
> * *
> **
>
> INCLUDE COND=(01,20,SS,EQ,C'LISTDSD DATASET', * ONLY LISTDSD RECS
> OR,
> 01,20,SS,EQ,C' 00 ', * OWNER RECORDS
> OR,
> 10,20,SS,EQ,C' ALTER ', * ALTER ACCESS
> OR,
> 10,20,SS,EQ,C'CONTROL ', * CONTROL ACCESS
> OR,
> 10,20,SS,EQ,C' READ ', * READ ACCESS
> OR,
> 10,20,SS,EQ,C'UPDATE ') * UPDATE ACCESS
>
>
> * *
> * PARSE THE INPUT RECORDS LOOKING FOR THE LITERALS REPRESENTING *
> * THE LISTDSD, OWNER AND RACF ID/ACCESS (DIFFERENT RECORDS) *
> * USING A GROUP OF THREE RECORDS (1=LISTDSD 2=OWNER 3=RACF ID) *
> * OVERLAY THE WORK AREA DATA IN 101-132 WITH: *
> * 101-104 = 'RACF' *
> * 105-150 = 45 CHARACTERS FOR LISTDSD NAME *
> * 151-158 = OWNER NAME *
> * 159-166 = RACF ID *
> * 167 175 = RACF ID ACCESS ALLOWED *
> * 181-184 = FOUR DIGIT RECORD NUMBER *
> * 185-186 = TWO DIGIT GROUP ID NUMBER *
> * 187-189 = THREE DIGIT SEQUENCE NUMBER *
> * 190-190 = RECORD TYPE; 1=LISTDSD 2=OWNER 3=RACF ID/ACCESS *
> * 191-193 = '123' RECORD TYPES *
> * 201-245 = 45 CHARACTERS FOR LISTDSD NAME *
> * 246-253 = EIGHT CHANRATER OWNER NAME *
> * 254-261 = EIGHT CHANRATER RACF ID *
> * 262-268 = SEVEN CHARACTER RACF ACCESS AVAILABLE *
> * *
> INREC IFTHEN=(WHEN=INIT,
> BUILD=(001,080, * CURRENT RECORD
> 101:C'RACF', * LITERAL
> 105:C'LISTDSD', * LISTDSD DATASET
> 151:C'OWNER', * OWNER
> 159:C'RACF ID', * RACF ID
> 167:C'ACCESS', * RACF ID ACCESS
> 181:SEQNUM,4,ZD, * RECNUM
> 191:C'123')), * REC TYPE
>
> *
> * WE INITIALIZE THE LISTDSD IN 201-245
> *
> IFTHEN=(WHEN=INIT,
> PARSE=(%01=(STARTAFT=C'LISTDSD DATASET(',
> ENDBEFR=C')',
> FIXLEN=45)),
> OVERLAY=(201:%01)), * LISTDSD
>
> *

Having some challenges with a SORT Utility

[Cameron Conacher]

,
PARSE=(%02=(STARTAFT=C' 00',
ENDBEFR=C' ',
FIXLEN=8)),
 OVERLAY=(246:%02)), * OWNER

*
*   WE INITIALIZE THE RACF ID IN 254-270
*
IFTHEN=(WHEN=INIT,
PARSE=(%03=(STARTAFT=C' ',
ENDBEFR=C' ',
FIXLEN=17)),
 OVERLAY=(254:%03)), * RACF DATA

*
*   IF WE CAN FIND THE LISTDSD DATA ITEM
*   SAVE THE LISTDSD IN 105-149
*
IFTHEN=(WHEN=GROUP,
   BEGIN=(01,50,SS,EQ,C'LISTDSD DATASET('),
   RECORDS=3,* COMBINING LISTDSD
   PUSH=(105:201,45, * LISTDSD
 185:ID=2,SEQ=3,
 190:191,001)),  * REC TYPE=1

*
*   IF WE CAN FIND OWNER IDENTIFIER
*   SAVE THE OWNER VALUE IN 151-158
*
IFTHEN=(WHEN=GROUP,
   BEGIN=(01,50,SS,EQ,C' 00'),
   RECORDS=2,* COMBINING OWNER
   PUSH=(150:246,08, * OWNER TAG
 187:SEQ=3,
 185:ID=2,SEQ=3,
 190:192,001)),  * REC TYPE=2

*
*   IF WE CAN FIND RACF ID/ACCESS
*   SAVE THE UPDATEABLE VALUE IN 120-122
*   OF THE THREE RECORD TYPES WE SELECTED, ONLY THE RACF
*   RECORD WILL HAVE A SPACE IN COLUMN 11.
*
IFTHEN=(WHEN=GROUP,
   BEGIN=(10,01,CH,EQ,C' ',AND,02,02,CH,GE,C' '),
   RECORDS=400,  * COMBINING RACF
   PUSH=(159:254,08, * RACF ID
 167:264,07, * RACF ACCESS
 185:ID=2,SEQ=3,
 190:193,001))   * REC TYPE=3
*
*
 SORT FIELDS=COPYLISTDSD

 OUTFIL FNAMES=TRACEIT

*
* THERE ARE THREE RECORDS IN THE SORTED FILE FOR EVERY DDNAME
* THE DATA WE WANT IN THE SORTED FILE IS FROM RECORD TYPE='3'
* 101-104 = 'RACF'
* 105-149 = LISTDSD DATASET NAME
* 150-157 = OWNER TAG IDENTIFIER
* 159-166 = RACF ID
* 167-173 = RACF ID ACCESS
*
 OUTFIL FNAMES=RACFOUT,
 INCLUDE=(190,001,CH,EQ,C'3'),
 OUTREC=(101,076)

 END




Thanks

Cameron Conacher
Senior Engineer II

American Express Canada Inc.
GCICS
2225 Sheppard Avenue East, Toronto, ON  M2J 5C2

cameron.conac...@aexp.com<mailto:cameron.conac...@aexp.com>
Office: 1-437-836-5265
Mobile: 1-416-409-5147

https://amex.webex.com/join/cameron.conacher



American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a ?t? envoy? par un repr?sentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les exp?diteurs par courriel.

Ce courriel est r?serv? au seul destinataire indiqu? et peut renfermer des 
renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire 
pr?vu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez re?u ce courriel par erreur, veuillez en aviser 
l'exp?diteur par courriel et d?truire imm?diatement le courriel et toute pi?ce 
jointe. Merci.

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

Re: What not to do on a z/OS system...

[Cameron Conacher]

A very long time ago, (mid seventies I think) I was loading a tape to a tape 
drive.
A button on my jean jacket trapped the edge of my jacket sleeve inside the tape 
drive when as the glass closed.
I stood patiently and waited for the tape processing to complete so the tape 
could unload.

After that, I paid more attention when loading tapes.

Thanks,

...Cameron





From: IBM Mainframe Discussion List  On Behalf Of 
Kirk Wolf
Sent: Wednesday, January 19, 2022 9:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: What not to do on a z/OS system...

Hooray! Now we've got the kind of thread that is the life blood of ibm-main :-)

On Wed, Jan 19, 2022, at 7:21 AM, John McKown wrote:
> I know of one MVT operator who trapped his girlfriend against a 3725
> communication controller and dropped a university's entire network.
> Multiple sites.
>
>

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

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

American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a ?t? envoy? par un repr?sentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les exp?diteurs par courriel.

Ce courriel est r?serv? au seul destinataire indiqu? et peut renfermer des 
renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire 
pr?vu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez re?u ce courriel par erreur, veuillez en aviser 
l'exp?diteur par courriel et d?truire imm?diatement le courriel et toute pi?ce 
jointe. Merci.

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

Re: article about ransomeware and mainframe

[Cameron Conacher]

I heard that the old computer rooms only had a dog and a human.
The human’s job was to feed the dog, and the dog’s job was to ensure the human 
did not touch anything.

Merry Christmas.

…….Cameron


Vacation Alert: I will be OOO from December 9th 2021 though to January 4th 2022 
inclusive.




From: IBM Mainframe Discussion List  On Behalf Of 
Colin Paice
Sent: Wednesday, December 22, 2021 3:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: article about ransomeware and mainframe

Someone told me the most unreliable part of a computer system is the
human.
Perhaps z/OS people are more cautious, or do not run email on their system,
and so less chance of running evil code.
I heard that people can get fake covid passports because someone one on the
inside can add fake records to the database. So no matter how secure your
system is...it is the soft flabby bit that lets it down.
Colin


On Tue, 21 Dec 2021 at 22:41, Seymour J Metz 
mailto:sme...@gmu.edu>> wrote:

> The devil is in the details. Suggesting useless tests while overlooking
> essential tests can make people less likely to discover their security
> issues.I would have stressed that there are managerial exposures and
> technological exposures; deal with both types else sooner or later your
> system will be compromised.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List 
> [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Erik Janssen [eaw.jans...@gmail.com]
> Sent: Tuesday, December 21, 2021 2:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: article about ransomeware and mainframe
>
> The article itself may contain some errors and misunderstandings, but the
> conclusion is absolutely spot on. Some people still maintain the idea that
> z/OS is better that linux and even windows in terms of security. Sadly,
> this believe and lack of urgency means that all z/OS shops that are not
> recent on their maintenance today are running with zero day exploits in APF
> authorized routines that leave them extremely vulnerable.
>
> Kind regards,
> Erik Janssen.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu 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

American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: AWS is down.

[Cameron Conacher]

And a very Merry Christmas to all.

Thanks,

…….Cameron


Vacation Alert: I will be OOO from December 9th 2021 though to January 4th 2022 
inclusive.




From: IBM Mainframe Discussion List  On Behalf Of Joe 
Monk
Sent: Wednesday, December 8, 2021 10:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: AWS is down.

Gents, please. No body cares.


Joe

On Wed, Dec 8, 2021, 22:05 Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu>
 wrote:

> No, I quoted IBM I/O claims. Of the mainframe. Even cut & pasted from the
> IBM manual. But, we all know you like to always think you’re right. Parsing
> stuff is your narcissist MO, looking for little things that really aren’t
> even part of the original reason for the thread. The fact is the mainframe
> is far more secure, way more available, faster, and unlikely to lose to the
> cloud vendors any of the real lucrative critical business. AWS holds my
> photos, for free. And I’m fine them not being available now & then. IBM’s
> mainframe business will be around far longer than you and I will be alive.
> Making sure your financial information is secure and always available,
> making sure your health care and pharmaceutical information is HIPAA
> protected and available for any emergencies that arrive, making sure your
> insurance claims are paid in a timely manner, making air reservations less
> stressful than air travel itself, allowing major retailers the ability to
> process the billions of transactions they require daily. IBM fanboy? Hell
> yes.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Wednesday, December 8, 2021, 9:18 PM, Seymour J Metz 
> mailto:sme...@gmu.edu>>
> wrote:
>
> You started saying 1 microsecond and retreated to 4, which is still a long
> way from 500. And you're a falure as a telepath; you don't have a clue what
> I'm thinking.
>
> My MO is to act as if facts matter.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List 
> [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Bill Johnson 
> [0047540adefe-dmarc-requ...@listserv.ua.edu]
> Sent: Wednesday, December 8, 2021 8:59 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: AWS is down.
>
> “Four microseconds is also nonsense”, is exactly what Metz said. He STATED
> that. I knew exactly what game he was playing from the very start. It’s his
> MO. Narcissism is what narcissists must do. I’m here to get facts, not play
> games trying to be friends. Knowing who the experts are is more important
> than the nonsense some people post or how often they post. It’s really
> pretty simple. You want zOS facts, Relson is the guy. You want SMP/E
> expertise, Kurt Q is the oracle.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Wednesday, December 8, 2021, 8:18 PM, patrickfalcone7 <
> 012526080649-dmarc-requ...@listserv.ua.edu>
>  wrote:
>
> Don't like to get into these but I have respect for Seymour and would ask
> you not to fan flames. While I understand Seymour's response he didn't
> necessarily state anything but questioned the possibility.Seymour I did not
> mean to put you in any unnecessary positions and apologize if I did. My
> post was only to state what metrics I've seen in the last couple of years.
> And you'd be surprised at how many might not know that it is possible to
> get mics on average with even backleveled kits.When we did our last array
> upgrade we went from 4 mills to around 400 to 500 mics. To me that is
> significant and ended up being so. I saw workload shifts in time due to the
> significance of the array swap.Sent from my Verizon, Samsung Galaxy
> smartphone
>  Original message From: Bill Johnson <
> 0047540adefe-dmarc-requ...@listserv.ua.edu>
>  Date: 12/8/21 4:07 PM
> (GMT-05:00) To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: AWS is down.
> LOLOLOLOL, I love when the so called “experts” are proven wrong.Sent from
> Yahoo Mail for iPhoneOn Wednesday, December 8, 2021, 4:04 PM,
> patrickfalcone7 
> <012526080649-dmarc-requ...@listserv.ua.edu>
> wrote:Hope you are well. FWIW I've seem mics for sometime but mostly under
> favorable conditions. But lately have found mics on average from under 5 on
> avg. mills.with somewhat newer array technology on < z15 CPCs.Sent from my
> Verizon, Samsung Galaxy smartphone Original message From:
> Seymour J Metz mailto:sme...@gmu.edu>> Date: 12/8/21 9:05 AM 
> (GMT-05:00) To:
> IBM-MAIN@LISTSERV.UA.EDU Subject: Re: AWS is 
> 

Re: AWS is down.

[Cameron Conacher]

Perhaps it is a mainframe opportunity?

Thanks,

…….Cameron


Vacation Alert: I will be OOO from December 9th 2021 though to January 4th 2022 
inclusive.




-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Tuesday, December 7, 2021 11:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: AWS is down.

+1

Different strokes for different folks. AWS's failure is not a mainframe success.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of kekronbekron
Sent: Tuesday, December 7, 2021 8:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AWS is down.

Not at anybody in particular:

Do we have to make snide remarks because someone else had an outage?
Don't we remember the times when things on the mainframe itself went south?
Has every site's MF env. been 100% available through all these decades?
Is it wrong to fail sometimes?
Is this the attitude with which you'd like to retire, holding onto precious 
remarks and burning the path behind you as you leave?
What does that say about one's mentality and outlook in life?

- KB

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

American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: Moron of the day -- me!

[Cameron Conacher]

Thank you! Thank you!!

…….Cameron




-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Wednesday, November 10, 2021 12:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Moron of the day -- me!

Yesterday I needed to run a quick test of a USS-resident program from batch, 
which I certainly knew was possible but had never done before. Found various 
pages talking about how to use BPXBATCH, tried it. RC=0 but no program output. 
None. Zero. Nada. Tinkered with DDs for STDOUT and STDERR (SYSOUT=*), no joy. 
Tried routing to DASD, no joy. Scratched head, gave up for the day.



Looked at it again this morning and saw the problem instantly. Now, as we all 
know, there is no new JCL: every bit of JCL is descended from a fragment found 
on a stone tablet on the side of a mountain near Poughkeepsie back in the early 
1960s. Every "new" job is just an old job, modified.



And it happened that the job I'd taken as my template had TYPRUN=SCAN.
Wasn't even aware I had any such.!



Presumably I won't make that mistake again.*



...phsiii



*This week


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

American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: ADRDSSU and encrypted files

[Cameron Conacher]

Hello there,
We decided to encourage our security folks to install the encryption master 
keys in the new environment and proceed from there.

Thanks to everyone who responded.

…….Cameron




-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ron 
Hawkins
Sent: Friday, November 5, 2021 5:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: ADRDSSU and encrypted files

Cameron,

I have forgotten more than I knew, and searching manuals no longer comes easy. 
Someone earlier mentioned using REPRO to decrypt the file as you back it up.

DF/dss will use REPRO for a logical backup, and the backup file is not 
encrypted.

The question then is, "When restoring, does DF/dss require the target dataset 
to be encrypted from a logical backup?"

Ron

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Glenn Wilcock
Sent: Friday, 5 November 2021 2:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] ADRDSSU and encrypted files

Hi Cameron, to answer your base question... No, ADRDSSU does not support 
decrypting an encrypted file during the dump process.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu 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

American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: ADRDSSU and encrypted files

[Cameron Conacher]

Yeah,
Don't encrypt original, or provide Master Encryption Keys to new environment.
I was hoping for the magical incantation for ADRDSSU to do exactly what I need 
without me actually doing anything.

Thanks everyone,

…….Cameron




-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter x23353
Sent: Wednesday, November 3, 2021 4:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: ADRDSSU and encrypted files

The OP already said that the new location has no master keys set up in the CEC 
yet, so no encryption is available there at all.

Perhaps the old-fashioned way?  IDCAMS REPREO to unencrypted sequential and 
ADRDSSU DUMP the unencrypted sequential file for DEFINE/REPRO at the receiving 
end.  A bit more work, but not too much, though it AssUMes that the creation of 
unencrypted sequential is even allowed in the originating location.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Wednesday, November 3, 2021 3:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ADRDSSU and encrypted files

There are published ways of transferring your keys to read your encrypted files.

On Wed, Nov 3, 2021 at 6:25 PM Cameron Conacher 
<03cfc59146bb-dmarc-requ...@listserv.ua.edu> wrote:
>
> The issue is we have a new environment.
> We need to move our data to the new environment.
> The new environment has no Master Encryption Keys. Yet.
> I can read the original file (I have access).
> I DUMP and send to the new environment and the file is encrypted, and without 
> keys, I cannot read it.
>
> Pervasive Encryption is working just as I would expect.
> I suppose, I simply cannot use ADRDSSU to DUMP/RESTORE.
> I can plan around that.
>
> Thanks,
>
> ...Cameron
>
>
>
>
> From: IBM Mainframe Discussion List  On
> Behalf Of Seymour J Metz
> Sent: Wednesday, November 3, 2021 2:13 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [External] Re: ADRDSSU and encrypted files
>
> Is that something that your management allows? At some places that would be a 
> massive security violation.
>
> ____
> From: IBM Mainframe Discussion List
> mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf
> of Cameron Conacher
> <03cfc59146bb-dmarc-requ...@listserv.ua.edu<mailto:03cfc59146b
> b-dmarc-requ...@listserv.ua.edu>>
> Sent: Wednesday, November 3, 2021 2:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
> Subject: ADRDSSU and encrypted files
>
> Hello folks,
> I have a situation here where I want to use ADRDSSU to DUMP a VSAM file (it 
> is encrypted) and then transfer the DUMP file to another system where 
> encryption is not supported.
> When I restore the files in the target environment, the VSAM file shows as 
> encrypted, but since I have no keys the file cannot be read.
>
> My question is, "is there anyway to tell ADRDSSU DUMP or RESTORE" to decrypt 
> the file before duping or before restoring?
>
>
> Thanks
--

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

American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courr

Re: ADRDSSU and encrypted files

[Cameron Conacher]

The issue is we have a new environment.
We need to move our data to the new environment.
The new environment has no Master Encryption Keys. Yet.
I can read the original file (I have access).
I DUMP and send to the new environment and the file is encrypted, and without 
keys, I cannot read it.

Pervasive Encryption is working just as I would expect.
I suppose, I simply cannot use ADRDSSU to DUMP/RESTORE.
I can plan around that.

Thanks,

...Cameron




From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Wednesday, November 3, 2021 2:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: ADRDSSU and encrypted files

Is that something that your management allows? At some places that would be a 
massive security violation.


From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of 
Cameron Conacher 
<03cfc59146bb-dmarc-requ...@listserv.ua.edu<mailto:03cfc59146bb-dmarc-requ...@listserv.ua.edu>>
Sent: Wednesday, November 3, 2021 2:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: ADRDSSU and encrypted files

Hello folks,
I have a situation here where I want to use ADRDSSU to DUMP a VSAM file (it is 
encrypted) and then transfer the DUMP file to another system where encryption 
is not supported.
When I restore the files in the target environment, the VSAM file shows as 
encrypted, but since I have no keys the file cannot be read.

My question is, "is there anyway to tell ADRDSSU DUMP or RESTORE" to decrypt 
the file before duping or before restoring?


Thanks

Cameron Conacher
Senior Engineer II

American Express Canada Inc.
GCICS
2225 Sheppard Avenue East, Toronto, ON M2J 5C2

cameron.conac...@aexp.com<mailto:cameron.conac...@aexp.com><mailto:cameron.conac...@aexp.com<mailto:cameron.conac...@aexp.com>>
Office: 1-437-836-5265
Mobile: 1-416-409-5147

https://amex.webex.com/join/cameron.conacher



American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, 
http://secure-web.cisco.com/1Y9VERYesi4oe2FZdm28Sz0KCYr-iCPCndjTmFbTvEGSVsZr7-xVDYCQHE9LcxktlYMYwUBOwZ5UNJl9lR4ZAci4sYUk8Z1lvs0SA-02_m9wY9eTIzoYDi6654B9r6ZE0iSF1wW0ihScW4S4U__BP_NmbsfH8gEmll5ZoeaeBCIYfCqYyeJ3uGPWEGBiz6L_1hQERvMO0e0LMkoBsyqFklI66wNquSVQZ4m_df-_1o8WbnRANIILTE3KOVnhqh2j5KKpr2PnDR-T2L1SJIWdFGaWjmq-Aj5J7FG5BoEfCqiW01XuN4am8X4st9Vwr6VvAbI2QhvqkJr-5jAgPC49bxKhmpfNiRB-VJsdCJ2A5UPkRM1pN-_OWm2huZGudqtYXAv_gBDfDxKHk749NPM9FnqP1gp4CVrsnkOFnhBggc0yFiHo2WcH2jVTZapDNBpH7/http%3A%2F%2Fwww.americanexpress.ca<https://isolate.menlosecurity.com/1/3735928037/http:/secure-web.cisco.com/1Y9VERYesi4oe2FZdm28Sz0KCYr-iCPCndjTmFbTvEGSVsZr7-xVDYCQHE9LcxktlYMYwUBOwZ5UNJl9lR4ZAci4sYUk8Z1lvs0SA-02_m9wY9eTIzoYDi6654B9r6ZE0iSF1wW0ihScW4S4U__BP_NmbsfH8gEmll5ZoeaeBCIYfCqYyeJ3uGPWEGBiz6L_1hQERvMO0e0LMkoBsyqFklI66wNquSVQZ4m_df-_1o8WbnRANIILTE3KOVnhqh2j5KKpr2PnDR-T2L1SJIWdFGaWjmq-Aj5J7FG5BoEfCqiW01XuN4am8X4st9Vwr6VvAbI2QhvqkJr-5jAgPC49bxKhmpfNiRB-VJsdCJ2A5UPkRM1pN-_OWm2huZGudqtYXAv_gBDfDxKHk749NPM9FnqP1gp4CVrsnkOFnhBggc0yFiHo2WcH2jVTZapDNBpH7/http%3A%2F%2Fwww.americanexpress.ca>.
 If you no longer wish to receive these e-mails, please notify the sender by 
reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a ?t? envoy? par un repr?sentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, 
http://secure-web.cisco.com/1Y9VERYesi4oe2FZdm28Sz0KCYr-iCPCndjTmFbTvEGSVsZr7-xVDYCQHE9LcxktlYMYwUBOwZ5UNJl9lR4ZAci4sYUk8Z1lvs0SA-02_m9wY9eTIzoYDi6654B9r6ZE0iSF1wW0ihScW4S4U__BP_NmbsfH8gEmll5ZoeaeBCIYfCqYyeJ3uGPWEGBiz6L_1hQERvMO0e0LMkoBsyqFklI66wNquSVQZ4m_df-_1o8WbnRANIILTE3KOVnhqh2j5KKpr2PnDR-T2L1SJIWdFGaWjmq-Aj5J7FG5BoEfCqiW01XuN4am8X4st9Vwr6VvAbI2QhvqkJr-5jAgPC49bxKhmpfNiRB-VJsdCJ2A5UPkRM1pN-_OWm2huZGudqtYXAv_gBDfDxKHk749NPM9FnqP1gp4CVrsnkOFnhBggc0yFiHo2WcH2jVTZapDNBpH7/http%3A%2F%2Fwww.americanexpress.ca<https://isolate.menlosecurity.com/1/3735928037/http:/secure-web.cisco.com/1Y9VERYesi4oe2FZdm28Sz0KCYr-iCPCndjTmFbTvEGSVsZr7-xVDYCQHE9LcxktlYMYwUBOwZ5UNJl9lR4ZAci4sYUk8Z1lvs0SA-02_m9wY9eTIzoYDi6654B9r6ZE0iSF1wW0ihScW4S4U__BP_NmbsfH8gEmll5ZoeaeBCIYfCqYyeJ3uGPWEGBiz6L_1hQERvMO0e0LMkoBsyqFklI66wNquSVQZ4m_df-_1o8WbnRANIILTE3KOVnhqh2j5KKpr2PnDR-T2L1SJIWdFGaWjmq-Aj5J7FG5BoEfCqiW01XuN4am8X4st9Vwr6VvAbI2QhvqkJr-5jAgPC49bxKhmpfNiRB-VJsdCJ2A5UPkRM1pN-_OWm2huZ

ADRDSSU and encrypted files

[Cameron Conacher]

Hello folks,
I have a situation here where I want to use ADRDSSU to DUMP a VSAM file (it is 
encrypted) and then transfer the DUMP file to another system where encryption 
is not supported.
When I restore the files in the target environment, the VSAM file shows as 
encrypted, but since I have no keys the file cannot be read.

My question is, "is there anyway to tell ADRDSSU DUMP or RESTORE" to decrypt 
the file before duping or before restoring?


Thanks

Cameron Conacher
Senior Engineer II

American Express Canada Inc.
GCICS
2225 Sheppard Avenue East, Toronto, ON  M2J 5C2

cameron.conac...@aexp.com<mailto:cameron.conac...@aexp.com>
Office: 1-437-836-5265
Mobile: 1-416-409-5147

https://amex.webex.com/join/cameron.conacher



American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a ?t? envoy? par un repr?sentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les exp?diteurs par courriel.

Ce courriel est r?serv? au seul destinataire indiqu? et peut renfermer des 
renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire 
pr?vu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez re?u ce courriel par erreur, veuillez en aviser 
l'exp?diteur par courriel et d?truire imm?diatement le courriel et toute pi?ce 
jointe. Merci.

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

Re: System Programmer Titles

[Cameron Conacher]

I tried o get "King" once, but that did not get very far.

Thanks,

…….Cameron




-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Brian Westerman
Sent: Tuesday, October 12, 2021 1:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: System Programmer Titles

I am leaning towards "He who shall not be called after midnight without 
invoking his considerable wrath", but I don't think it would fit on my card.

Brian

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

American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: PL/I vs. JCL

[Cameron Conacher]

Honestly, I do not know, but I read it as A F T cargo hatch.
As in the south end of a north bound developer.

Thanks,

…….Cameron




-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Monday, October 4, 2021 9:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: PL/I vs. JCL

Ok, I give up.  I have favorite-newscaster stories, too, but I don't get this 
one.  What's an EFT cargo hatch?  Is this so obvious a failure that I'll be 
required by law to kick myself when it's explained to me, or something that 
only pilots know, or what?

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

/* By definition, a government has no conscience. Sometimes it has a policy, 
but nothing more.  -Albert Camus */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Sunday, October 3, 2021 13:22

--- On Sun, 3 Oct 2021 09:37:00 -0700, Skip Robinson wrote:
A long time favorite is a local newscaster who read a story attributing a DC-10 
crash to a failure of an "eh-eff-tee cargo hatch."

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

American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: DCOLLECT & DFSORT

[Cameron Conacher]

Four bytes binary to display numeric?
Starting-column,4,bi,EDIT=(TTTS)
Maybe be what you are looking for?

Packed date to display numeric?
Starting-column,4,PD,EDIT=(TTT)
Maybe what you are looking for?

If you want leading zeros use “T”
If you want leading zeroes as blanks use “I”.

Sent from my iPhone

> On Aug 3, 2021, at 9:17 AM, Steve Smith  wrote:
> 
> I use a format item of E'.999' on the field specified as length 4, type
> PD... I'm not sure of the syntax on a typical SORT, as I always use symbol
> files, and ICETOOL DISPLAY for this sort of thing.
> 
> sas
> 
>> On Tue, Aug 3, 2021 at 8:27 AM Jack Zukt  wrote:
>> 
>> Hello All,
>> I am trying to build a report of inactive datasets using DCOLLECT for input
>> and DFSORT to create the files for each last year referenced.
>> For the output files I only want the dataset name; last used date;
>> allocated space; used space; storage group name. Now for the tricky part: I
>> want the date and space fields translated to characters. On the DCOLLECT
>> input records the date is in the 'dddF' format and the space fields are
>> 4 byte long signed. I am pretty sure that there is a way to tell DFSORT to
>> make that translation but I am having no luck with the manual.
>> Any suggestions?
>> Thank you for any help that you may give me.
>> Regards
>> Jack
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu 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: Global Mirror Distances

[Cameron Conacher]

Thank you.

Sent from my iPhone

> On May 22, 2021, at 12:39 PM, Radoslaw Skorupka  
> wrote:
> 
> Two things to consider:
> 1. Distance => delay. For long distances it means synchronous copy is not 
> applicable. It can be asynchronous copy or some kind of "fuzzy" copy like 
> PPRC-XD or SRDF Adaptive Copy.
> 
> 2. Bandwidth and I/O rate. The more I/O the higher bandwidth is needed for 
> replication. Temporary spikes are managed by "delta", but it doesn't mean you 
> can do a lot of I/O during business hours and rebalance delta on evening. It 
> is complex topic, especially when fuzzy copy is considered.
> 
> BTW: Before you start you can establish some POC configuration. There are 
> devices simulating distance (delay) and bandwidth limitation.  So, you can 
> have 9000 miles in single computer room.
> Note: it is not 9000 miles of fiber optic in a suitcase - such devices are 
> actually used for much shorter distances (10-20km) and rather for synchronous 
> copy.
> 
> 
> -- 
> Radoslaw Skorupka
> (looking for new job)
> Lodz, Poland
> 
> 
> 
> 
> 
> 
> W dniu 21.05.2021 o 21:34, Cameron Conacher pisze:
>> Hello folks,
>> I am trying to find out what we could consider to be a "safe" maximum
>> distance for mirroring DASD from one site to another.
>> We have a situation where site #1 will be thousands (9,000) of miles away
>> from site #2 (across the ocean.
>> 
>> I realize there would be a great deal of latency involved.
>> But is this even possible or is it simply a non-starter?
>> 
>> The second question I have is, suppose that I waved a magic wand and
>> suddenly all my data was sitting comfortably in site #2.
>> Could I (again ignoring latency for the moment) run a batch JOB or CICS
>> transactions in site #1 that accessed the data 9,000 miles away in site #2?
>> My thought here was if the data must absolutely be relocated, and
>> people are willing to accept there will be latency, can we just access the
>> DASD at site #2, rather than building a large data centre and performing
>> all of the processing in site #2?
>> Even if we run the processing at site #2, there will be many interfaces
>> between site #1 and site #2.
>> 
>> I know there are hard distance limitations.
>> I think Global Mirror is limited to about 1500 miles.
>> And I would hazard a guess that remote DASD would not be viable either.
>> 
>> But I wanted to see if someone really "knows", rather than something I may
>> have mis-remembered.
>> 
>> Any thoughts/opinions are appreciated.
>> 
>> Thanks
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu 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: Global Mirror Distances

[Cameron Conacher]

Thank you.

Sent from my iPhone

> On May 21, 2021, at 7:39 PM, Mike Schwab  wrote:
> 
> Async mirroring would be possible.  The bad / good thing is your
> source dasd track could be updated several times between passes.  What
> the controller does is look at the updated track table, 1 bit per
> track, copies the tracks in order, resetting the bits when read and
> acknowledged, then proceeds to the next track.  When it gets all those
> tracks copied, it reads the updated track table for the next pass.
> 
> If you process the updated tracks fast enough, the number of tracks to
> send drops with each pass until updates are sent almost immediately.
> If you process the updated tracks too slow, then the number of tracks
> to send keeps growing.
> 
> The key is the transmission rate to the endpoint.  I think the last
> time I heard the limit was continent wide, because the links between
> continents simply didn't have enough throughput capacity to get the
> secondary up to speed.  Even with the land bridge, N/S America is
> pretty slow, and African links too, despite cables across the
> Mediteranian.  Maybe Europe / Asian would not be too bad.  Antarctica
> is satellite only.
> 
> Australia is a long separation.  I had a friend in Australia who kept
> getting notifications that her password was changed in Shanghai China,
> so she changed it, got the message again, and repeated a few times.  I
> pointed out that that was probably where the Australian underwater
> cable came ashore and the location registered, because the date time
> of the change was when she changed her password.
> 
> https://www.submarinecablemap.com/
> 
>> On Fri, May 21, 2021 at 2:34 PM Cameron Conacher  wrote:
>> 
>> Hello folks,
>> I am trying to find out what we could consider to be a "safe" maximum
>> distance for mirroring DASD from one site to another.
>> We have a situation where site #1 will be thousands (9,000) of miles away
>> from site #2 (across the ocean.
>> 
>> I realize there would be a great deal of latency involved.
>> But is this even possible or is it simply a non-starter?
>> 
>> The second question I have is, suppose that I waved a magic wand and
>> suddenly all my data was sitting comfortably in site #2.
>> Could I (again ignoring latency for the moment) run a batch JOB or CICS
>> transactions in site #1 that accessed the data 9,000 miles away in site #2?
>> My thought here was if the data must absolutely be relocated, and
>> people are willing to accept there will be latency, can we just access the
>> DASD at site #2, rather than building a large data centre and performing
>> all of the processing in site #2?
>> Even if we run the processing at site #2, there will be many interfaces
>> between site #1 and site #2.
>> 
>> I know there are hard distance limitations.
>> I think Global Mirror is limited to about 1500 miles.
>> And I would hazard a guess that remote DASD would not be viable either.
>> 
>> But I wanted to see if someone really "knows", rather than something I may
>> have mis-remembered.
>> 
>> Any thoughts/opinions are appreciated.
>> 
>> Thanks
>> 
>> --
>> 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

Global Mirror Distances

[Cameron Conacher]

Hello folks,
I am trying to find out what we could consider to be a "safe" maximum
distance for mirroring DASD from one site to another.
We have a situation where site #1 will be thousands (9,000) of miles away
from site #2 (across the ocean.

I realize there would be a great deal of latency involved.
But is this even possible or is it simply a non-starter?

The second question I have is, suppose that I waved a magic wand and
suddenly all my data was sitting comfortably in site #2.
Could I (again ignoring latency for the moment) run a batch JOB or CICS
transactions in site #1 that accessed the data 9,000 miles away in site #2?
My thought here was if the data must absolutely be relocated, and
people are willing to accept there will be latency, can we just access the
DASD at site #2, rather than building a large data centre and performing
all of the processing in site #2?
Even if we run the processing at site #2, there will be many interfaces
between site #1 and site #2.

I know there are hard distance limitations.
I think Global Mirror is limited to about 1500 miles.
And I would hazard a guess that remote DASD would not be viable either.

But I wanted to see if someone really "knows", rather than something I may
have mis-remembered.

Any thoughts/opinions are appreciated.

Thanks

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

Re: IBM PCOMM - copy/paste doesnt work

[Cameron Conacher]

We had some upgrade applied a year or so ago.
Afterwards I could not copy and paste.
I did the following:
Edit -> Preferences -> Keyboard
Browse
Choose 1.kemp
Open
Restart session

Your mileage may vary, but that did the trick for me.

Sent from my iPhone

> On Mar 30, 2021, at 8:02 AM, kekronbekron 
> <02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Galaxy brain time, folks:
> 
> There's an option in PCOMM that automatically copies whatever* to the 
> clipboard.
> 
> whatever* = anything you draw a bounding box over. Selection tool or whatever 
> it's called.
> And there's a setting to not persist the display of the bounding box, after 
> the above operation is done.
> 
> No keyboard shortcuts necessary.
> 
> - KB
> 
> ‐‐‐ Original Message ‐‐‐
>> On Tuesday, March 30, 2021 5:14 PM, Radoslaw Skorupka 
>>  wrote:
>> 
>> W dniu 30.03.2021 o 11:45, Peter pisze:
>> 
>>> Hello
>>> I am unable to.copy or paste within and to any outside application like
>>> notpad.
>>> When I do Alt +e+c and try to paste within or outside I get blank. Tried
>>> resetting keyboard 3270 but no luck.
>>> Is there any kind of trace options I can enable within 3270 pcom emulator
>>> to verify the strokes ?
>> 
>> I met such problems, but it was related to Windows problems, not PCOMM
>> itself. Especially when RDP is in use.
>> BTW: I strongly suggest to customize keyboard : Ctrl-C and Ctrl-V
>> instead of pulldown menu.
>> 
>> Few hints:
>> Use COPY (alt-e-c) without selecting anything on the screen. In such
>> case whole screen should be copied.
>> Try to select some text, regular text (without special chars) and paste.
>> Try to use copy-paste from Notepad to PCOMM (inversely)
>> Try to use copy-paste from PCOMM to PCOMM.
>> Obviously use COPY-PASTE between other apps, like two Notepad windows,
>> Excel, etc.
>> 
>> 
>> -
>> 
>> Radoslaw Skorupka
>> (looking for new job)
>> Lodz, Poland
>> 
>> -
>> 
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Can I use a REXX PLIST when calling a COBOL program?

[Cameron Conacher]

Thank you.

On Mon, Mar 22, 2021 at 8:35 PM Seymour J Metz  wrote:

> REXX-aware means that it can handle an EFPL as described at <
> https://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sa320972/$file/ikja300_v2r4.pdf#page=290
> >
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Cameron Conacher [conac...@gmail.com]
> Sent: Monday, March 22, 2021 2:53 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Can I use a REXX PLIST when calling a COBOL program?
>
> Paul,
> when you say that my COBOL program must be coded Rexx-aware, do you mean I
> need to work with IRXEXCOM to tease the parameters out from REXX?
> I appreciate everyone's input.
> I don't know if the "appropriate" path forward is to use ADDRESS LINK or
> ADDRESS LINKMVS or if I should continue to try to make the CALL work.
> I don't want to waste anyone's time (other than my own).
>
> I will keep playing around to see if I can figure this out.
>
>
>
> On Mon, Mar 22, 2021 at 2:09 PM Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> > On Mon, 22 Mar 2021 17:50:00 +, Seymour J Metz wrote:
> >
> > >You are using CALL, which is intended for REXX procedures and REXX-aware
> > procedure that are written to accept an external function parameter list
> > (EFPL).
> > >
> > Which may be OK if REXXEXCI is coded Rexx-aware and reformats it
> > argument as required by EXCI.
> >
> > > ... Use ADDRESS LINK or ADDRESS LINKMVS to call a main program and
> > ADDRESS LINKPGM to call a subroutine. Note that if the subroutine is
> > written in COBOL then you also have the issue of LE to deal with.
> > >
> > LINKMVS generates a 2-byte length à la JCL "PARM=".  LINKPGM , like
> > Assembler CALL, requires the programmer to supply the length
> > ("d2c(length( PARM ), 2) || PARM") but can be used for subroutines
> > not expecting such a length.
> >
> > -- gil
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Can I use a REXX PLIST when calling a COBOL program?

[Cameron Conacher]

REXXEXCI is my program.
I pass some parameters to the program, and it issues an EXEC-CICS LINK to
jump across EXCI into the CICS region to run a non-terminal transaction. I
pass the APPLID of the CICS region, and a program name to run, and a
transaction code to run the program under etc...
I don't have any issue writing COBOL code to manage the EXCI aspects.
I can code to the LINK interface or I can code to the CALL interface.

The area where I am a bit thin is in the REXX arena.
I guess I will just work with the ADDRESS LINKMVS format and pass the
individual parameters.
I thought I would be able to do something cute by putting all the parms
into a PLIST and then calling my COBOL program.
I was able to put all the parms into a PLIST and then call an assembler
routine, so I thought How much more work could it be to go directly to
COBOL?

Anyway again, I appreciate everyone's patience and assistance here.


On Mon, Mar 22, 2021 at 3:25 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 22 Mar 2021 14:53:02 -0400, Cameron Conacher  wrote:
> >
> >when you say that my COBOL program must be coded Rexx-aware, do you mean I
> >need to work with IRXEXCOM to tease the parameters out from REXX?
> >
> Perhaps that code exists in REXXEXCI.
>
> >I appreciate everyone's input.
> >I don't know if the "appropriate" path forward is to use ADDRESS LINK or
> >ADDRESS LINKMVS or if I should continue to try to make the CALL work.
> >I don't want to waste anyone's time (other than my own).
> >
> >I will keep playing around to see if I can figure this out.
> >
> Oh my!
>
> o CALL invokes a Rexx subroutine (which might be coded in Assembler
>   with Rexx-like linkage.)
> o 'CALL' (quoted) issues the TSO (or other command environment)
>   to invoke a program object with a JCL-like PARM. (Or do something
>   else.)
> o address 'LINKMVS' invokes a program object with one (or more
>   JCL-like PARMs.  (JCL allows at most one.)
> o address 'LINKPGM' is close to the CALL macro interface.
> o address 'LINK' is sui generis.  I suspect it's a residue of
>   CMS conventions.
>
> TSO-REXX LISTSERV might correct some of my misconceptions.
>
> Is a description of REXXEXCI readily available?  It seems to be
> a CICS thing.
>
> -- 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: Can I use a REXX PLIST when calling a COBOL program?

[Cameron Conacher]

Paul,
when you say that my COBOL program must be coded Rexx-aware, do you mean I
need to work with IRXEXCOM to tease the parameters out from REXX?
I appreciate everyone's input.
I don't know if the "appropriate" path forward is to use ADDRESS LINK or
ADDRESS LINKMVS or if I should continue to try to make the CALL work.
I don't want to waste anyone's time (other than my own).

I will keep playing around to see if I can figure this out.



On Mon, Mar 22, 2021 at 2:09 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 22 Mar 2021 17:50:00 +, Seymour J Metz wrote:
>
> >You are using CALL, which is intended for REXX procedures and REXX-aware
> procedure that are written to accept an external function parameter list
> (EFPL).
> >
> Which may be OK if REXXEXCI is coded Rexx-aware and reformats it
> argument as required by EXCI.
>
> > ... Use ADDRESS LINK or ADDRESS LINKMVS to call a main program and
> ADDRESS LINKPGM to call a subroutine. Note that if the subroutine is
> written in COBOL then you also have the issue of LE to deal with.
> >
> LINKMVS generates a 2-byte length à la JCL "PARM=".  LINKPGM , like
> Assembler CALL, requires the programmer to supply the length
> ("d2c(length( PARM ), 2) || PARM") but can be used for subroutines
> not expecting such a length.
>
> -- 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: Can I use a REXX PLIST when calling a COBOL program?

[Cameron Conacher]

My REXX looks like this.
Previously, I passed one long string to my COBOL program as PARM5SS.
Now I am trying to create a PLIST to pass to my COBOL Program.
I do not really know what I am doing with this. I am just trying to figure
it out.
I could do it one way. I wanted to see if I could do it another way.

TRACE 'A'

COMMAREA = SUBSTR('UIF2087A 2012001',1,126)

COMMAREA_LEN = LENGTH(COMMAREA)

DATALENGTH = LENGTH(COMMAREA)



USER_ID = 'IF2087A '

APPLID  = 'DHIPO158'

PROGRAM_NAME = 'Z7XG5SS '

OPERATION = 'A'

SMSF_ID = SUBSTR('FREDRICK',1,20)

RETURN_SWITCH = 'N'

RETURN_MESSAGE = SUBSTR('MESSAGE SENT TO REXXEXCI',1,80)



PARM5SS = SUBSTR('IF2087A DHIPO158Z7XG5SS AFREDDAY',1,126)





PARM = 'USERID('USER_ID') APPLID('APPLID') PROGRAM('PROGRAM_NAME')' ,

   'OPERATION('OPERATION') SMSFID('SMSF_ID')' ,

   'RETURNSWITCH('RETURN_SWITCH') RETURNMESSAGE('RETURN_MESSAGE')'





SAY 'COMMAREA CONTENTS BEFORE LINK ARE:' COMMAREA





CALL REXXEXCI PARM





SAY 'MAIN EXEC - RESULT VARIABLE CONTENTS:' RESULT

SAY

SAY 'TRACE_LOC IS:' TRACE_LOC



On Mon, Mar 22, 2021 at 1:11 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 22 Mar 2021 16:48:29 +, Seymour J Metz  wrote:
>
> >What environment did you use in your ADDRESS statement? Please post the
> relevant REXX code.
> >
> For example, here's an excerpt of my Rexx code.  I could have used LINKMVS.
> Values could be returned in the PARMs.
>
> PARM1 = ''
> Nulls = left('', 8, '00'x)
> PARM2 = Nulls  || , /* 1*/
> Nulls  || , /* 2*/
> Nulls  || , /* 3*/
> Nulls  || , /* 4*/
> G.9CTRL|| , /* SYSIN*/
> G.9IEBOUT  || , /* SYSPRINT */
> Nulls  || , /* 7*/
> IDD|| , /* SYSUT1   */
> JobOut  /* SYSUT2   */
> /* ... */
> address 'ATTCHMVS' 'IEBGENER PARM1 PARM2'
> IEBRC = RC
>
> >
> >From: Cameron Conacher
> >Sent: Monday, March 22, 2021 12:44 PM
> >
> >I am not sure I understand now.
> >I created a simple COBOL Program and added a number of 01 level items to
> >the Linkage section and then I added PROCEDURE DIVISION USING... a list of
> >the data items I expected to see passed from my little REXX EXEC.
> >LINKAGE SECTION.
> >01 parameter-1 PIC X(08)
> >01 parameter-2 PIC X(08)
> >01 parameter-3 PIC X(20)
> >
> >PROCEDURE DIVISION USING parameter-1, parameter-2, parameter-3.
> >
> >I create a PLIST in REXX and called my dumb program passing the PLIST PARM
> >and then dumped the Linkage parameters.
> >
> >From what I can see when I look at the items in HEX, I get a two byte
> >binary length followed by something that looks like a pointer.
> >len= x'000A' and pointer is x'000130E1'
> >But none of the PARMs are actually ten bytes long, and the address seems
> >wrong to me.
>
> -- 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: Can I use a REXX PLIST when calling a COBOL program?

[Cameron Conacher]

I am not sure I understand now.
I created a simple COBOL Program and added a number of 01 level items to
the Linkage section and then I added PROCEDURE DIVISION USING... a list of
the data items I expected to see passed from my little REXX EXEC.
LINKAGE SECTION.
01 parameter-1 PIC X(08)
01 parameter-2 PIC X(08)
01 parameter-3 PIC X(20)

PROCEDURE DIVISION USING parameter-1, parameter-2, parameter-3.

I create a PLIST in REXX and called my dumb program passing the PLIST PARM
and then dumped the Linkage parameters.

>From what I can see when I look at the items in HEX, I get a two byte
binary length followed by something that looks like a pointer.
len= x'000A' and pointer is x'000130E1'
But none of the PARMs are actually ten bytes long, and the address seems
wrong to me.

Have I misunderstood something here?

On Mon, Mar 22, 2021 at 12:00 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 22 Mar 2021 14:34:58 +, Seymour J Metz  wrote:
>
> >The PLIST format is the same regardless of language; for AMODE 24 or
> AMODE 31 it's just a list of pointers with the high bit of the last pointer
> set. However, the Devil is in the details.
> >
> Indeed.  If the objects addressed by pointers in the PLIST are control
> blocks containing pointers to areas the caller must create, Rexx is
> unsuited to the task.  E.g. such parameters make the SMP/E API
> unsuitable to Rexx.  In contrast, the ICSF API wisely uses only
> pointers in the PLIST which can be created by ADDRESS LINKMVS,
> the programmer using D2C(), etc..
>
> >If you are calling a main program, REXX handles everything. If you are
> calling a program that doesn't expect a specific runtime environment, e.g.,
> LE, to have been initialized, then as long as you can create the proper
> parameters, REXX handles everything. I don't know of any way to call a
> program that expects an existing LE environment or that requires any input
> beyond R14-R1.
>
> -- 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: Can I use a REXX PLIST when calling a COBOL program?

[Cameron Conacher]

Thanks everyone.


On Mon, Mar 22, 2021 at 10:35 AM Seymour J Metz  wrote:

> The PLIST format is the same regardless of language; for AMODE 24 or AMODE
> 31 it's just a list of pointers with the high bit of the last pointer set.
> However, the Devil is in the details.
>
> If you are calling a main program, REXX handles everything. If you are
> calling a program that doesn't expect a specific runtime environment, e.g.,
> LE, to have been initialized, then as long as you can create the proper
> parameters, REXX handles everything. I don't know of any way to call a
> program that expects an existing LE environment or that requires any input
> beyond R14-R1.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Cameron Conacher [conac...@gmail.com]
> Sent: Monday, March 22, 2021 9:12 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Can I use a REXX PLIST when calling a COBOL program?
>
> Hello everyone,
> I have been busy playing with an old support pac from IBM that enables REXX
> to call an Assembler routine that in turn invokes EXCI.
> Not terribly important, but I thought the PLIST interface between REXX and
> Assembler was pretty slick. I had not seen it before. (and the support pac
> was from 1996!)
>
> It got me to wondering if I could do something similar with REXX calling a
> COBOL routine.
> Can I pass a PLIST from REXX to a COBOL program?
>
> If I can pass the PLIST, do I need to parse the pointer list myself, or can
> I just list out the linkage section items in the order I expect them.
>
> Thanks for any thoughts,
>
> ...Cameron
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu 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: Can I use a REXX PLIST when calling a COBOL program?

[Cameron Conacher]

Thank you Brian.
This is helpful.

Sent from my iPhone

> On Mar 22, 2021, at 9:22 AM, Brian Chapman  wrote:
> 
> Cameron,
> 
> If you add the data areas to the PROCEDURE DIVISION USING statement, then
> COBOL will set the linkage accordingly.
> 
> 
> 
> Thank you,
> 
> Brian Chapman
> 
> 
>> On Mon, Mar 22, 2021 at 9:13 AM Cameron Conacher  wrote:
>> 
>> Hello everyone,
>> I have been busy playing with an old support pac from IBM that enables REXX
>> to call an Assembler routine that in turn invokes EXCI.
>> Not terribly important, but I thought the PLIST interface between REXX and
>> Assembler was pretty slick. I had not seen it before. (and the support pac
>> was from 1996!)
>> 
>> It got me to wondering if I could do something similar with REXX calling a
>> COBOL routine.
>> Can I pass a PLIST from REXX to a COBOL program?
>> 
>> If I can pass the PLIST, do I need to parse the pointer list myself, or can
>> I just list out the linkage section items in the order I expect them.
>> 
>> Thanks for any thoughts,
>> 
>> ...Cameron
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu 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 I use a REXX PLIST when calling a COBOL program?

[Cameron Conacher]

Hello everyone,
I have been busy playing with an old support pac from IBM that enables REXX
to call an Assembler routine that in turn invokes EXCI.
Not terribly important, but I thought the PLIST interface between REXX and
Assembler was pretty slick. I had not seen it before. (and the support pac
was from 1996!)

It got me to wondering if I could do something similar with REXX calling a
COBOL routine.
Can I pass a PLIST from REXX to a COBOL program?

If I can pass the PLIST, do I need to parse the pointer list myself, or can
I just list out the linkage section items in the order I expect them.

Thanks for any thoughts,

...Cameron

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

Re: VSAM file discrepancies

[Cameron Conacher]

A KSDS with duplicate full primary key values? 
Are you sure?

Sent from my iPhone

> On Jan 19, 2021, at 10:19 AM, Steff Gladstone  
> wrote:
> 
> Greetings,
> 
> We are trying to figure out how a VSAM file became compromised. That is,
> even though the primary key is unique, when we do a REPRO, we see that the
> data contains an extra record with the same key.
> 
> The file is updated from two different computers via a batch COBOL program.
> The share options are (4,3) and an enqueue (with parameter SYSTEMS) is
> performed (using an assembler subroutine) before any update is done.  The
> site has a 3rd-party product from CA that propagates the ENQ from one
> computer to the other.  We even tested the ENQ and saw that an update from
> the second computer was blocked when the first computer previously issued
> an ENQ prior to its update.
> 
> It looks as if an update in one computer has not been committed from memory
> to disk before the update in the second computer occurs.  Which definitions
> are lacking that would prevent this from happening?
> 
> Thanks in advance,
> Steff Gladstone
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu 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

A couple of CICS questions for today. (1-BMS; 2-SYNCPOINT rule-of-thumb)

[Cameron Conacher]

Good morning folks,
I have a couple of CICS related questions for today.
I have been using CICS since the mid seventies. I should remember this, but
I just can't recall.
I am creating a BMS Map.
I have a number of detail data lines that repeat a number of times.
In the past I have created little assembler macros in the BMS Map to
describe one line and then repeat the definitions for some number of lines.
Something like this.
  MACRO
  SXREF  =
   SETA 
.
.
a bunch of DFHMDFs.
.
prefix DFHMDF blah blah
prefix2 DFHMDF blah blah
 .
 MEND

Then I have my DFHMDI followed by a number of these:
SXREF ROW=05
SXREF ROW=06
SXREF ROW=07
SXREF ROW=08
SXREF ROW=09
SXREF ROW=10
SXREF ROW=11
SXREF ROW=12
This all works fine, however the DFHMDF Field Definitions are created
without leading zeros. (SETA)
So I see fields like prefix1I (when =05) as well as prefix10I (when
%ROW=15)

My question is how I can make the first definition to look something like
prefix01I (when =05)
I hope this is making sense.
I know I can do this by crafting two MACROs (one for items 1-9 and another
for 10+), but I was curious if someone has some other technique?

Last question for today
I have a CICS Program which processes log data that is in an Intrapartition
Transient Data Queue.
The program is triggered from the TDQ which was set with a trigger level of
+1.
When the program runs, it copies everything in the TDQ to an RLS Managed
VSAM file.
Again, everything is fine here.
When the program runs, because it copies ALL the queue data, it will
request some number of locks on the VSAM file.
A lot of TDQ data means many locks.
I plan to add a SYNCPOINT into the program to clear the locks.
So, the question today is if someone has a "rule-of-thumb" ... take a
SYNCPOINT after 100 write or 1,000 writes or 10,000 writes... or

Thanks

...Cameron

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

[Cameron Conacher]

I just run a batch JOB. I set the FROMCODE to 1208 and the TOCODE to IBM-1047

Sent from my iPhone

> On Nov 16, 2020, at 8:09 PM, Wayne Bickerdike  wrote:
> 
> I use iconv too. Had to jump through some hoops to get ASCII event binds to
> new environments.
> 
> I use something along the lines of iconv -f IBM-1047 -t ISO8859 FIX1 > $5
> 
> This is done after a sed command to do some string conversion..
> 
>> On Tue, Nov 17, 2020 at 11:06 AM Cameron Conacher 
>> wrote:
>> 
>> You could send it in binary and then use iconv to transform to EBCDIC.
>> 
>> Sent from my iPhone
>> 
>>> On Nov 16, 2020, at 4:27 PM, Frank Swarbrick <
>> frank.swarbr...@outlook.com> wrote:
>>> 
>>> 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
>>> 
>>> ---

Re: FTP converting between UTF-8 and EBCDIC

[Cameron Conacher]

You could send it in binary and then use iconv to transform to EBCDIC.

Sent from my iPhone

> On Nov 16, 2020, at 4:27 PM, Frank Swarbrick  
> wrote:
> 
> 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

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

Re: Another DFSORT Question

[Cameron Conacher]

Hello Sri,
Argh!! Yes too many assumptions...
1) True. Not thinking of DSN on a separate line.
2) True. Step names can be single characters.
3) A temporary Dataset still has a Dataset Name, or a Dataset Name
reference, right?
4) I did not know DMBATCH could have SYSIN2.
5) True. This was my attempt at ignoring any sequence numbers that might be
in 73-80.

The reason for this exercise is that in some situations, the DMNETMAP and
DMMSGFIL DataSet Names need to be modified.
The Dataset Names need to have a newer value when certain conditions are
met in the NDM control statements.
I first tried scanning all of our Control Statement libraries and found
over 80,000 possibilities.
Then I thought I could check the JCL and PROCS, and grab a list with all
the JCL/PROC Member Names and their associated DMNETMAP, DMMSGFIL, and
SYSIN dataset names.
Then from this list I could ignore the JOBs where the Dataset Names have
already been updated.
This gives me a much smaller list. Several hundred items.
Then I will need to check each of the associated SYSIN members manually to
determine if any changes may be required.

Anyway, thanks for taking some time to explain this.

On Thu, Oct 29, 2020 at 7:53 PM Sri h Kolusu  wrote:

> > The control statements below work fine. They do what I wanted.
> > Today my question is if these SORT Control statements can be optimized?
> > This is not urgent.
>
>
> Cameron,
>
> Your job definitely can be optimized.  But I want to make a observation
> that you might be skipping some results.
>
> You are assuming that the ddnames DMNETMAP and DMSGFIL have the dataset
> name on the same line.
>
> 1. ) For example if your input has the following Input, you will NOT pick
> the DSN names
>
>
>
> //DMNETMAP DD DISP=SHR,
> //DSN=$HLQ.NETMAP
> //DMPUBLIB DD DISP=SHR,
> // DD DSN=$HLQ.PROCESL
> //DMMSGFIL DD DISP=OLD,
> //DSN=$HLQ.MSG4
>
>
> 2.) Similarly the stepnames can any where from 1 byte to 8 bytes, however
> your picking bytes from 4 thru 8 . Assume the following input
>
> //S1 EXEC PGM=DMBATCH,REGION=1024K,PARM=(YYSLYNN) .
>
>
>
> 3.) What happens if SYSIN cards are generated from previous step as a temp
> dataset and passed over to DMBATCH step?
>
> ex:
>
> https://www.ibm.com/support/pages/how-submit-instream-process-jcl-using-dgadbatc-dmbatch
>
> Check how  & is generated.
>
> How do you plan to handle the & contents?
>
>
> 4.) Also the program DMBATCH can have SYSIN2 also, do you plan to extract
> the information?
>
>
> 5.)  Technically SYSIN can be a PDS with member name. So the maximum length
> of PDS+Member = 54 bytes  ( 44 Dsn name+ 8 byte member name + 2 byte for
> opening and closing parenthesis).  However your control cards don't seem to
> be handling them.
>
> Let me know the answers to be above questions and I will show you the
> optimized control cards.
>
>
> Thanks,
> Kolusu
> DFSORT Development
> IBM Corporation
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu 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

Another DFSORT Question

[Cameron Conacher]

Hello ,
I have put together this set of SORT control statements to scan through an
IEBPTPCH dump of a JCL or PROC PDS.
The DFSORT statements will look for any JOB Steps that execute program
DMBATCH (this is an NDM Program).
The statements will gather up some DD Statement information related to the
program.
I wanted to collect the DMNETMAP, DMMSGFIL and the SYSIN Control Statements
data set names.
The SYSIN could be a concatenated sequence of datasets.

The control statements below work fine. They do what I wanted.
Today my question is if these SORT Control statements can be optimized?
This is not urgent.
Any ideas are appreciated.

Thanks,

**

**

*  SCAN THROUGH THE IEBPTPCH STREAM AND GENERATE AN OUTPUT FILE. *

**

*  WE IGNORE ALL COMMENT RECORDS.*

*  WE ONLY SELECT RECORDS WITH THE SCANNED PDS MEMBER NAMEAND*

* RECORDS THAT EXECUTE PROCNAME  *

*  THE OUTPUT FROM THE PROCESS WILL HAVE *

* JCL/PROC LIBRARY NAME IN 001 THROUGH 003   *

* JCL/PROC MEMBER NAME  IN 005 THROUGH 012   *

* DMNETMAP DATASET NAME IN 014 THROUGH 058   *

* DMMSGFIL DATASET NAME IN 060 THROUGH 104   *

* SYSIN DATASET NAMEIN 106 THROUGH 150   *

**

**



  OMIT COND=(02,03,CH,EQ,C'//*',OR, * SKIP COMMENTS

 (02,02,CH,NE,C'//',AND,

  2,11,CH,NE,C'MEMBER NAME'))   * SKIP DATA RECORDS



*

*  THE MEMBER GROUP STARTS WITH THE "MEMBER NAME" RECORD.

*

  INREC IFTHEN=(WHEN=GROUP,

   BEGIN=(2,11,CH,EQ,C'MEMBER NAME'),

PUSH=(082:SEQ=8,* SEQUENCE #

  091:15,08)),  * JCL MEMBER NAME



*

*  THE DMBATCH GROUP APPLIES TO THE ENTIRE DMBATCH STEP.

*  IT BEGINS WITH "PGM=DMBATCH" AND WILL END AFTER THE

*  DMBATCH STEP.

*

IFTHEN=(WHEN=GROUP,

   BEGIN=(4,40,SS,EQ,C'PGM=DMBATCH'),

   END=(004,05,CH,NE,C'SYSIN',AND,

004,05,CH,NE,C' ',AND,

1PUSH=(099:04,08)),  *
STEP NAME



*

*  THE DMNETMAP GROUP APPLIES TO THE ENTIRE DMBATCH STEP.

*  IT BEGINS WITH THE DDNAME, AND ENDS WITH THE NEXT

*  EXEC STATEMENT.

*

IFTHEN=(WHEN=GROUP,

   BEGIN=(4,08,CH,EQ,C'DMNETMAP'),

   END=(4,20,SS,EQ,C' EXEC '),

PUSH=(107:21,40)),  * DMNETMAP DSN



*

*  THE DMMSGFIL GROUP APPLIES TO THE ENTIRE DMBATCH STEP.

*  IT BEGINS WITH THE DDNAME, AND ENDS WITH THE NEXT

*  EXEC STATEMENT.

*

IFTHEN=(WHEN=GROUP,

   BEGIN=(4,08,CH,EQ,C'DMMSGFIL'),

   END=(4,20,SS,EQ,C' EXEC '),

PUSH=(147:21,40)),  * DMMSGFIL DSN



*

*  GROUP STARTS WITH SYSIN DD STATEMENT AND ENDS

*  WHEN ANY CONCATENATION SEQUENCE ENDS.

*

IFTHEN=(WHEN=GROUP,

   BEGIN=(4,05,CH,EQ,C'SYSIN'),

   END=(4,05,CH,NE,C'SYSIN',AND,

4,05,CH,NE,C' '),

PUSH=(187:04,05)),  * SYSIN



IFTHEN=(WHEN=(187,05,CH,EQ,C'SYSIN',AND,* INSTREAM RECORDS

  012,40,SS,EQ,C' * '),

 BUILD=(001:JP1,* LIBRARY DATASET

C',',

005:091,08, * MEMBER NAME

C',',

014:107,40, * DMNETMAP DATASET

C',',

055:147,40, * DMMSGFIL DATASET

C',',

096:C'INSTREAM SYSIN DD * DATA',

C',',

137:099,08, * DMBATCH STEP NAME

145:C'*')),



IFTHEN=(WHEN=(187,05,CH,EQ,C'SYSIN',AND,* DATASET NAME

  017,40,SS,EQ,C'DSN='),

 BUILD=(001:JP1,* LIBRARY DATASET

C',',

005:091,08, * MEMBER NAME

C',',

014:107,40, * DMNETMAP DATASET

C',',

055:147,40, * DMMSGFIL DATASET

C',',

096:021,40, * SYSIN DATASET

C',',

137:099,08, * DMBATCH STEP NAME

145:C'D'))

Re: DFSORT Question

[Cameron Conacher]

Thank you both.

Sent from my iPhone

> On Oct 26, 2020, at 3:55 PM, Sri h Kolusu  wrote:
> 
> Martin,
> 
> Like minds think alike :)
> 
> Thanks,
> Kolusu
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu 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 Question

[Cameron Conacher]

Sri
Could you refer me to some documentation to help me better understand the 
differences between BUILD and OVERLAY?

Sent from my iPhone

> On Oct 26, 2020, at 1:10 PM, Sri h Kolusu  wrote:
> 
> Cameron,
> 
> OUTFIL is  last on the list of processing.  i.e
> 
> INCLUDE
> INREC
> SORT
> OUTREC
> OUTFIL
> 
> 
> So your traceit will be printed after OUTREC. Ideally I would use an
> OVERLAY instead of BUILD, so that I can see what exactly what was picked.
> 
> I optimized your control cards a bit so (clubbed multiple conditions into a
> single condition)
> 
> //STEP0100 EXEC PGM=SORT,PARM='JP1""'
> //SYSOUT   DD SYSOUT=*
> //SORTIN   DD DISP=SHR,DSN=Your IEBPTPCH source
> //SORTOUT  DD SYSOUT=*
> //TRACEIT  DD SYSOUT=*
> //SYSINDD *
>  INCLUDE COND=((2,3,CH,NE,C'//*'),AND,   * NO COMMENTS
>(((2,11,CH,EQ,C'MEMBER NAME'),OR, * MEMBER NAME
>  (5,30,SS,EQ,C' EXEC ')),AND,* EXEC PROC
>  (5,30,SS,NE,C'PGM=')))
> 
>  INREC IFTHEN=(WHEN=GROUP,
>   BEGIN=(2,11,CH,EQ,C'MEMBER NAME'),
>PUSH=(082:SEQ=8,  * SEQUENCE #
>  091:15,08)),* MEMBER NAME
> 
>IFTHEN=(WHEN=(18,05,CH,EQ,C'PROC '),
> OVERLAY=(100:23,08,  * PROCNAME
>  SQZ=(SHIFT=LEFT,PREBLANK=C','),
>  110:JP1,* LIBRARY NAME
>  160:C'P')),
> 
>IFTHEN=(WHEN=(11,05,CH,EQ,C'EXEC ',OR,
>  12,05,CH,EQ,C'EXEC ',OR,
>  13,05,CH,EQ,C'EXEC ',OR,
>  14,05,CH,EQ,C'EXEC '),
>   PARSE=(%01=(STARTAFT=C'EXEC ',
>ENDBEFR=C',',
> FIXLEN=8)),
> OVERLAY=(100:%01,* PROCNAME
>  110:JP1,* LIBRARY NAME
>  162:C'P'))
> 
>  SORT FIELDS=(091,08,CH,A,   * MEMBER NAME
>   100,08,CH,A)   * PROC NAME
> 
>   SUM FIELDS=NONE
> 
>  OUTFIL INCLUDE=(162,1,CH,EQ,C'P'),
>  BUILD=(82,80,SQZ=(SHIFT=LEFT,MID=C';'))
> 
>  OUTFIL FNAMES=TRACEIT
> /*
> 
> 
> If you wish to see the contents before SORT and eliminating the dups (SUM),
> then it is quite simple
> 
> Change your SYSIN to the following (use a COPY operation). By default
> DFSORT will write out to the DDname SORTOUT.  So check the contents from
> position 82 thru 162.
> 
> 
> //SYSINDD *
>  INCLUDE COND=((2,3,CH,NE,C'//*'),AND,   * NO COMMENTS
>(((2,11,CH,EQ,C'MEMBER NAME'),OR, * MEMBER NAME
>  (5,30,SS,EQ,C' EXEC ')),AND,* EXEC PROC
>  (5,30,SS,NE,C'PGM=')))
> 
>  INREC IFTHEN=(WHEN=GROUP,
>   BEGIN=(2,11,CH,EQ,C'MEMBER NAME'),
>PUSH=(082:SEQ=8,  * SEQUENCE #
>  091:15,08)),* MEMBER NAME
> 
>IFTHEN=(WHEN=(18,05,CH,EQ,C'PROC '),
> OVERLAY=(100:23,08,  * PROCNAME
>  SQZ=(SHIFT=LEFT,PREBLANK=C','),
>  110:JP1,* LIBRARY NAME
>  160:C'P')),
> 
>IFTHEN=(WHEN=(11,05,CH,EQ,C'EXEC ',OR,
>  12,05,CH,EQ,C'EXEC ',OR,
>  13,05,CH,EQ,C'EXEC ',OR,
>  14,05,CH,EQ,C'EXEC '),
>   PARSE=(%01=(STARTAFT=C'EXEC ',
>ENDBEFR=C',',
> FIXLEN=8)),
> OVERLAY=(100:%01,* PROCNAME
>  110:JP1,* LIBRARY NAME
>  162:C'P'))
> 
>  OPTION COPY
> 
> /*
> 
> Further if you have any questions please let me know
> 
> Thanks,
> Kolusu
> DFSORT Development
> IBM Corporation
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu 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 Question

[Cameron Conacher]

Thank you Sri.
This is helpful.

On Mon, Oct 26, 2020 at 1:10 PM Sri h Kolusu  wrote:

> Cameron,
>
> OUTFIL is  last on the list of processing.  i.e
>
> INCLUDE
> INREC
> SORT
> OUTREC
> OUTFIL
>
>
> So your traceit will be printed after OUTREC. Ideally I would use an
> OVERLAY instead of BUILD, so that I can see what exactly what was picked.
>
> I optimized your control cards a bit so (clubbed multiple conditions into a
> single condition)
>
> //STEP0100 EXEC PGM=SORT,PARM='JP1""'
> //SYSOUT   DD SYSOUT=*
> //SORTIN   DD DISP=SHR,DSN=Your IEBPTPCH source
> //SORTOUT  DD SYSOUT=*
> //TRACEIT  DD SYSOUT=*
> //SYSINDD *
>   INCLUDE COND=((2,3,CH,NE,C'//*'),AND,   * NO COMMENTS
> (((2,11,CH,EQ,C'MEMBER NAME'),OR, * MEMBER NAME
>   (5,30,SS,EQ,C' EXEC ')),AND,* EXEC PROC
>   (5,30,SS,NE,C'PGM=')))
>
>   INREC IFTHEN=(WHEN=GROUP,
>BEGIN=(2,11,CH,EQ,C'MEMBER NAME'),
> PUSH=(082:SEQ=8,  * SEQUENCE #
>   091:15,08)),* MEMBER NAME
>
> IFTHEN=(WHEN=(18,05,CH,EQ,C'PROC '),
>  OVERLAY=(100:23,08,  * PROCNAME
>   SQZ=(SHIFT=LEFT,PREBLANK=C','),
>   110:JP1,* LIBRARY NAME
>   160:C'P')),
>
> IFTHEN=(WHEN=(11,05,CH,EQ,C'EXEC ',OR,
>   12,05,CH,EQ,C'EXEC ',OR,
>   13,05,CH,EQ,C'EXEC ',OR,
>   14,05,CH,EQ,C'EXEC '),
>PARSE=(%01=(STARTAFT=C'EXEC ',
> ENDBEFR=C',',
>  FIXLEN=8)),
>  OVERLAY=(100:%01,* PROCNAME
>   110:JP1,* LIBRARY NAME
>   162:C'P'))
>
>   SORT FIELDS=(091,08,CH,A,   * MEMBER NAME
>100,08,CH,A)   * PROC NAME
>
>SUM FIELDS=NONE
>
>   OUTFIL INCLUDE=(162,1,CH,EQ,C'P'),
>   BUILD=(82,80,SQZ=(SHIFT=LEFT,MID=C';'))
>
>   OUTFIL FNAMES=TRACEIT
> /*
>
>
> If you wish to see the contents before SORT and eliminating the dups (SUM),
> then it is quite simple
>
> Change your SYSIN to the following (use a COPY operation). By default
> DFSORT will write out to the DDname SORTOUT.  So check the contents from
> position 82 thru 162.
>
>
> //SYSINDD *
>   INCLUDE COND=((2,3,CH,NE,C'//*'),AND,   * NO COMMENTS
> (((2,11,CH,EQ,C'MEMBER NAME'),OR, * MEMBER NAME
>   (5,30,SS,EQ,C' EXEC ')),AND,* EXEC PROC
>   (5,30,SS,NE,C'PGM=')))
>
>   INREC IFTHEN=(WHEN=GROUP,
>BEGIN=(2,11,CH,EQ,C'MEMBER NAME'),
> PUSH=(082:SEQ=8,  * SEQUENCE #
>   091:15,08)),* MEMBER NAME
>
> IFTHEN=(WHEN=(18,05,CH,EQ,C'PROC '),
>  OVERLAY=(100:23,08,  * PROCNAME
>   SQZ=(SHIFT=LEFT,PREBLANK=C','),
>   110:JP1,* LIBRARY NAME
>   160:C'P')),
>
> IFTHEN=(WHEN=(11,05,CH,EQ,C'EXEC ',OR,
>   12,05,CH,EQ,C'EXEC ',OR,
>   13,05,CH,EQ,C'EXEC ',OR,
>   14,05,CH,EQ,C'EXEC '),
>PARSE=(%01=(STARTAFT=C'EXEC ',
> ENDBEFR=C',',
>  FIXLEN=8)),
>  OVERLAY=(100:%01,* PROCNAME
>   110:JP1,* LIBRARY NAME
>   162:C'P'))
>
>   OPTION COPY
>
> /*
>
> Further if you have any questions please let me know
>
> Thanks,
> Kolusu
> DFSORT Development
> IBM Corporation
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu 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 Question

[Cameron Conacher]

Hello Kolusu,
Yes that is correct.
Below I have included my SORT statements that work for me.
The issue I had was that originally, I also had an OUTREC BUILD IFTHEN.
When that was present, I had an error with the record length of the TRACEIT
file.
I am copying the intermediate file (after INREC processing) to the file
TRACEIT.
That way I can browse the file and ensure I have the correct byte alignment
when putting together the OUTFIL statements.
I hope that makes more sense now.
This is not a problem since everything works.
It was more a curiosity question.
When are the OUTFIL records actually written for TRACEIT?
Does it depend on whether or not OUTREC is present?

INREC
write the TRACEIT file here?
SORT
OUTREC

or

INREC
SORT
OUTREC
Write the TRACEIT file here?

I assume they are written after OUTREC processing because I saw record
length errors.
And, when I removed the OUTREC processing everything was fine.

Thank you,


*** *

*** *

**  SCAN THROUGH THE IEBPTPCH STREAM AND GENERATE AN OUTPUT FILE. * *

*** *

**  WE IGNORE ALL COMMENT RECORDS.* *

**  WE ONLY SELECT RECORDS WITH THE SCANNED PDS MEMBER NAMEAND* *

** RECORDS THAT EXECUTE PROCNAME  * *

**  THE OUTPUT FROM THE PROCESS WILL HAVE * *

** JCL MEMBER NAME   IN 001 THROUGH 008   * *

** JCL PDS LIBRARY NAME  IN 010 THROUGH 012   * *

** PROC NAME IN 016 THROUGH 021   * *

*** *

*** *



* INCLUDE COND=((2,3,CH,NE,C'//*'),AND,  * NO COMMENTS  *

*   (((2,11,CH,EQ,C'MEMBER NAME'),OR,* MEMBER NAME  *

* (5,30,SS,EQ,C' EXEC ')),AND,   * EXEC PROC*

* (5,30,SS,NE,C'PGM=')))*



**   *

** ALL PROC= START IN COLUMN 18 *

** EXEC PROCNAME; PROCNAME CAN BE IN COLUMNS 11, 12, 13, 14 *

**  *

* INREC IFTHEN=(WHEN=GROUP, *

*   BEGIN=(2,11,CH,EQ,C'MEMBER NAME'),  *

*   PUSH=(82:15,8,SEQ=8)),  *

*   IFTHEN=(WHEN=(18,04,CH,EQ,C'PROC'), *

*   BUILD=(90,08,C',',  * SEQUENCE #*

*  82,08,C',',  * JCL LIBRARY   *

*  JP1,C',',* JCL MEMBER NAME   *

*  23,08,   * PROC NAME *

*  SQZ=(SHIFT=LEFT,PREBLANK=C','))),*

*   IFTHEN=(WHEN=(14,04,CH,EQ,C'EXEC'), *

*   BUILD=(90,08,C',',  * SEQUENCE #*

*  82,08,C',',  * JCL LIBRARY   *

*  JP1,C',',* JCL MEMBER NAME   *

*  19,08,   * PROC NAME *

*  SQZ=(SHIFT=LEFT,PREBLANK=C','))),*

*   IFTHEN=(WHEN=(13,04,CH,EQ,C'EXEC'), *

*   BUILD=(90,08,C',',  * SEQUENCE #*

*  82,08,C',',  * JCL LIBRARY   *

*  JP1,C',',* JCL MEMBER NAME   *

*  18,08,   * PROC NAME *

*  SQZ=(SHIFT=LEFT,PREBLANK=C','))),*

*   IFTHEN=(WHEN=(12,04,CH,EQ,C'EXEC'), *

*   BUILD=(90,08,C',',  * SEQUENCE #*

*  82,08,C',',  * JCL LIBRARY   *

*  JP1,C',',* JCL MEMBER NAME   *

*  17,08,   * PROC NAME *

*  SQZ=(SHIFT=LEFT,PREBLANK=C','))),*

*   IFTHEN=(WHEN=(11,04,CH,EQ,C'EXEC'), *

*   BUILD=(90,08,C',',  * SEQUENCE #*

*  82,08,C',',  * JCL LIBRARY   *

*  JP1,C',',* JCL MEMBER NAME   *

*  16,08,   * PROC NAME *

*  SQZ=(SHIFT=LEFT,PREBLANK=C','))),*

* 

DFSORT Question

[Cameron Conacher]

Hello folks,
I put together a small process that runs an IEBPTPCH to generate a stream
from one of our JCL Libraries.
Then I ran a small DFSORT to pull out the combinations of JCL Member Name
and the PROC Names that are executed from the JOB.
Everything is fine.
I do not understand the high level flow of events though.
First I do an INCLUDE to select MEMBER NAME Records and records with " EXEC
" but not "PGM="
Then I do an INREC IFTHEN BUILD to reformat the input records.
Then I do an OUTPUT FNAMES so I can see the intermediate file contents.
Then SORT.
Then OUTFILE with BUILD.
Everything is fine here.
I believe I have understood this.

Now when I started down the path, I had the INCLUDE, and the INREC IFTHEN
BUILD sequence.
Then a SORT and then finally, an OUTREC IFTHEN BUILD.
This is where I became confused.
The SORT step failed because my intermediate file format no longer matched
the record length I expected.
I removed the OUTREC IFTHEN BUILD and made it OUTREC BUILD and things ran
fine.

I was under the impression that
1) Do the INREC processing assembling intermediate file records to release
to the SORT
2) Do the Sort
3) Process the SORT Records and generate the SORTOUT Formatted file.

When I have an INREC IFTHEN BUILD and I do not have an OUTREC IFTHEN BUILD,
I get an intermediate file before the SORT.
Once I add the IFTHEN to the OUTREC statement, it seems that my
intermediate file format has changed.

Maybe it is just something dumb like where I have put the OUTFILE(TRACELOG)
statement I use to capture the intermediate file contents?

This is not an urgent burning question. Everything is working fine for me
now.
But apparently, I do have a knowledge gap here.
This is just something I would like to understand a bit better.

Thanks,

...Cameron

I have an UTPUFT FNAMES

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

Re: EBCDIC and other systems

[Cameron Conacher]

Sorry, just saw this.
3270 emulators.
I use IBM PCOMM today, but I have used EXTRA and I have used Host on Demand.


On Thu, Aug 20, 2020 at 8:40 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 20 Aug 2020 17:45:09 -0400, Cameron Conacher wrote:
>
> >I have used Japanese (930) and traditional Chinese (937) with the
> appropriate EBCDIC Host Code Page.
> >So yes DBCS is supported on a green screen
> >
> Which terminals support these?
>
> I see that on MacOS and Linux both appear in the Options menu of x3270.
> I have no data to verify their operation.
>
>
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.f54em00/useofr1.htm
> ... implies that both are among the couple dozen code pages supported
> for coding Edit macros.  And, "in an Edit macro that is called from a batch
> Edit session (where no terminal is attached), code page 1047 is used."
>
> It's a pity that ISPF can't honor the CCSID in a macro tag so an author
> supporting a diverse community needn't supply multiple instances of
> macros for those various users.
>
> -- 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: EBCDIC and other systems

[Cameron Conacher]

I have used Japanese (930) and traditional Chinese (937) with the appropriate 
EBCDIC Host Code Page.
So yes DBCS is supported on a green screen

Sent from my iPhone

> On Aug 20, 2020, at 1:43 PM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Thu, 20 Aug 2020 09:35:40 -0700, Charles Mills wrote:
> 
>> I wonder if it might make sense to go UTF-32 even to disk, but compress the 
>> data.
>> 
>> I wonder how well standard compression schemes work with UTF-32? Are they 
>> too octet-oriented to work optimally?
>> 
> A non-scientific sample:
> 1995 $ ls -l ~ | wc
> 24 2131403
> 1996 $ ls -l ~ |gzip | wc
>  1   9 441
> 1997 $ ls -l ~ | iconv -f UTF-8 -t UTF-32 | wc
> 24 2135616
> 1998 $ ls -l ~ | iconv -f UTF-8 -t UTF-32 | gzip | wc
>  0   9 679
> 
>> I wonder if one might write an LZW implementation that assumed 32-bit 
>> characters.
> 
> -- 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: EBCDIC and other systems

[Cameron Conacher]

There are many EBCDIC codepages.
DBCS is used by japan, China, Korea and Vietnam.
Our Japanese customers use EBCDIC codepage 930. Our Taiwanese customers use 
EBCDIC codepage 937.


Sent from my iPhone

> On Aug 20, 2020, at 8:54 AM, Rupert Reynolds  wrote:
> 
> I'm writing a new OS for PC hardware (an exercise started during
> lockdown/furlough) and I wondered about files from other systems. Is there
> much in DBCS on mainframe systems these days, or is it still mainly the
> same old 8-bit EBCDIC, please?
> 
> I still have to decide whether to support UTF-8 and/or UTF-32, of course :-)
> 
> Roo
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu 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

JSON PARSE statement format ???

[Cameron Conacher]

Hello again everyone,
I have been trying to use the new JSON PARSE statement and I am having a
little difficulty in understanding what is really needed.

I have a JSON document that looks something along the lines of:
{"httpHeaders":{"traceID":"my trace id data","spanID":"my spanid data"}}

I pass this to my CICS COBOL PROGRAM, where I have a working storage area
like this:
05  WS01-CONTEXT-HEADERS.
  10  WS01-CH-TRACE-DATA PIC X(36).
  10  WS01-CH-SPAN-DATA PIC X(36).

In the program I have a JSON PARSE statement like this:
JSON PARSE my input UTF8 data
INTO  WS01-CH-CONTEXT-HEADERS
WITH DETAIL
NAME OF WS01-CONTEXT-HEADERS is 'httpHeaders'
 WS01-CH-TRACE-DATA is 'traceID'
 WS01-CH-SPAN-DATA is 'spanID'
END-JSON

Yes, I also have on exception 

In any event, when I run this, it does what I want it to do, specifically,
that WS01-CH data fields have the data I want after the PARSE completes.
However, since I have WITH DETAIL specified, I can see a few things in the
CICS Region logs.
A few IGZ0321I messages. IGZ0321I During execution of the JSON PARSE
statement on line 16801 of program MYPROGR, no JSON name/value TRACEID,
which was thus not modified.

huh?
I think this means that the JSON object did not contain a name/value pair
for "TRACEID".
Which is what is expected because I specified "NAME OF" in the parse
statement.
So is this just to inform me things were done as I requested?

I realize this is just an FYI, and it will disappear when I get rid of
"WITH DETAIL".
I explicitly said I had other variables I wanted to use.
The program ran and did what I wanted.
What if anything, can I do to remove this Informational message?

Last question, because I am curious.
This is an http CONTEXT Header coming in over a z/OS Connect POST CICS
Container request.
Can I modify anything in the Context Header in my COBOL program, and have
it returned to z/OS Connect outside of the actual Response Message
Container that goes back?
Somehow it just seems wrong to think about that. The CONTEXT HEADERS are
likely read only.
But I don't know enough yet to understand this.
And I am having way too much fun.

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

Re: UTF16 to EBCDIC

[Cameron Conacher]

Not sure what you are asking here.
The mainframe supports UTF-16BE Basic Mapping Plane 0 natively as National
Characters in COBOL - PIC N.

UTF-16 to UTF-8 would not lose any characters during transformation since
they both encode Unicode.


On Sun, Feb 9, 2020 at 6:21 PM Mike Schwab  wrote:

> Would UTF-16 to UTF-8 be a better conversion?  You still have to be
> certain of the source character set.  And is supported by some z/OS
> software.
>
> On Sun, Feb 9, 2020 at 11:55 AM Cameron Conacher 
> wrote:
> >
> > Ah yes,
> > I mis-typed/fat fingered the reply.
> > As you say, it SHOULD read EDCICONV.
> >
> > And, yes Unicode allows for over a million possible character
> combination.
> > National Language support in the mainframe allows for the characters in
> > basic mapping plane 0, so only about 65,000 character combinations.
> > And IBM-037 only has 256 combinations.
> > So, be aware of character loss as you transform from one to the other.
> >
> > On Sat, Feb 8, 2020 at 11:45 AM Paul Gilmartin <
> > 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > On Sat, 8 Feb 2020 09:09:58 -0600, Paul Gilmartin wrote:
> > >
> > > >On Sat, 8 Feb 2020 09:37:29 -0500, Cameron Conacher wrote:
> > > >
> > > >>I use ICONV.
> > > >>
> > > >>//MYSTEP EXEC PROC=EDICONV,
> > > >>//INFILE='MY.input.file.name(member)',
> > > >>//OUTFILE='My.Output.FileName',
> > > >>//FROMC='1208',
> > > >>//TOC='IBM-037'
> > > >>
> > > >>
> > > >>The PROC is licensed IBM material. It executes program EDICCONV
> > > >>
> > > >Is the documentation available only with purchase?
> > > >
> > > Ah!  Do you mean perhaps, JCL procedure EDCICONV?
> > >
> > >
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.cbcux01/iconvubatch.htm
> > >
> > > I wonder what was the motivation to require preallocated data set
> > > names rather than the more flexible alternative of DDNAMEs?
> > >
> > > >How does it handle characters absent from IBM-037?
> > > >
> > > >1208 is UTF-8, not UTF-16.  I assume the example is schematic.
> > >
> > > -- 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
>
>
>
> --
> 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

Re: UTF16 to EBCDIC

[Cameron Conacher]

Ah yes,
I mis-typed/fat fingered the reply.
As you say, it SHOULD read EDCICONV.

And, yes Unicode allows for over a million possible character combination.
National Language support in the mainframe allows for the characters in
basic mapping plane 0, so only about 65,000 character combinations.
And IBM-037 only has 256 combinations.
So, be aware of character loss as you transform from one to the other.

On Sat, Feb 8, 2020 at 11:45 AM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Sat, 8 Feb 2020 09:09:58 -0600, Paul Gilmartin wrote:
>
> >On Sat, 8 Feb 2020 09:37:29 -0500, Cameron Conacher wrote:
> >
> >>I use ICONV.
> >>
> >>//MYSTEP EXEC PROC=EDICONV,
> >>//INFILE='MY.input.file.name(member)',
> >>//OUTFILE='My.Output.FileName',
> >>//FROMC='1208',
> >>//TOC='IBM-037'
> >>
> >>
> >>The PROC is licensed IBM material. It executes program EDICCONV
> >>
> >Is the documentation available only with purchase?
> >
> Ah!  Do you mean perhaps, JCL procedure EDCICONV?
>
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.cbcux01/iconvubatch.htm
>
> I wonder what was the motivation to require preallocated data set
> names rather than the more flexible alternative of DDNAMEs?
>
> >How does it handle characters absent from IBM-037?
> >
> >1208 is UTF-8, not UTF-16.  I assume the example is schematic.
>
> -- 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: UTF16 to EBCDIC

[Cameron Conacher]

I use ICONV.

//MYSTEP EXEC PROC=EDICONV,
//INFILE='MY.input.file.name(member)',
//OUTFILE='My.Output.FileName',
//FROMC='1208',
//TOC='IBM-037'


The PROC is licensed IBM material. It executes program EDICCONV

On Thu, Feb 6, 2020 at 9:29 PM Jake Anderson 
wrote:

> Hi
>
> Cross posted
>
> I am looking way to translate from UTF16 to EBCDIC. When I do D UNI,ALL i
> do not see UTF16 to EBCDIC conversion table.
>
> Is it something I need to load as CUNIMG or I have to create a table then
> refer them while FTP ing ?
>
> Please advise
>
> Jake
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Creating VSAM data sets with DSNTYPE=EXTREQ

[Cameron Conacher]

Lenny,
I can't recall the issue with XCOM.
We run ZPSAVER SYNCSORT. This does not work with EF files, so the sorting
falls back to BSAM I believe, and there is a corresponding increase in MIPs.
We installed ZPSAVER to save MIPS and EF files throw these savings away. We
are talking to SYNCSORT folks.
With FIELAID, I found that if I encrypted a VSAM file, and then edited the
VSAM file using FIELAID, the updates were not actually saved to the file.
After doing a SAVE, and reopening the file, the updates were not there. We
are talking to CA FILEAID folks now.

The ISPW issue was not really related to encryption.
The issue is related to the sheer number of artifacts that are changing in
support of encryption.
I created a container with 20,000+ artifacts supporting the IDCAMS DEFINE
changes alone.
It took hours just to check out the items.
Now when I look at my container I can only see a subset of the actual
artifacts.
The items are all in the PDS library. It is just the ISPW system parm
setting is something like 1,000 items for me.
I could chop the work into multiple containers.

Eventually I will need to manage 100,000+ artifacts for JCL and PROCs. I
don't know how I will deal with that just yet.

Hope that helps.

On Thu, Jan 16, 2020 at 11:42 AM Lennie Dymoke-Bradshaw <
lenni...@rsmpartners.com> wrote:

> Cameron,
>
> Sadly I have no dataclas with extended specified and I do not want to have
> to produce more dataclas specifications at the moment.
>
> When you say " We have seen some issues with XCOM, SYNCSORT, FILEAID and
> ISPW" could you be more specific please?
>
> Thanks,
>
> Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd
> Web:  www.rsmpartners.com
> ‘Dance like no one is watching. Encrypt like everyone is.’
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Cameron Conacher
> Sent: 16 January 2020 16:00
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] Creating VSAM data sets with DSNTYPE=EXTREQ
>
> For IDCAMS DEFINE I added DATACLAS(extended dataclas name)
>
> For JCL and PROCs I added DATACLAS(...) as well
>
> If DATACLAS was already specified I just changed the name to an extended
> format name
>
> Don’t get me wrong. You can change the members but you still need to test
> and promote.
>
> We have seen some issues with XCOM, SYNCSORT, FILEAID and ISPW.
>
>
>
> Sent from my iPhone
>
> > On Jan 16, 2020, at 9:48 AM, Lennie Dymoke-Bradshaw <
> lenni...@rsmpartners.com> wrote:
> >
> > I am doing planning for the encryption of application data. I have a
> need to encrypt some fairly large numbers of VSAM datasets.
> >
> > I am trying to develop some tooling to help with the allocation and
> > encryption of the VSAM data sets. I need to define replacement data
> > sets which are extended format (DSNTYPE=EXTREQ in JCL terms). I can
> > allocate new data sets using the following methods,
> >
> >
> >  1.  IDCAMS: DEFINE CLUSTER with MODEL pointing at existing cluster.
> Using this method I can specify the names of the VSAM index and data
> components. However, I cannot see how to specify that I want extended
> format.
> >  2.  IDCAMS: ALLOCATE with LIKE specifying the original cluster name.
> Using this method I can specify DSNTYPE(EXTREQ), but I cannot specify the
> names of the data and index components.
> >  3.  IKJEFT01: ALLOCATE with LIKE specifying the original cluster name.
> This is identical to option 2 as IDCAMS will be invoking IKJEFT01 to do the
> allocation.
> >  4.  JCL: With this method I can again specify DSNTYPE=EXTREQ, but I
> cannot specify the names of the index and data components.
> >
> > At this stage I do not want to alter the existing SMS ACS routines.  Is
> there any way I can specify both the data and index component names and
> EXTREQ?
> >
> > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd
> > Web:  www.rsmpartners.com<http://www.rsmpartners.com/>
> > 'Dance like no one is watching. Encrypt like everyone is.'
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu 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: Creating VSAM data sets with DSNTYPE=EXTREQ

[Cameron Conacher]

For IDCAMS DEFINE I added DATACLAS(extended dataclas name)

For JCL and PROCs I added DATACLAS(...) as well

If DATACLAS was already specified I just changed the name to an extended format 
name 

Don’t get me wrong. You can change the members but you still need to test and 
promote.

We have seen some issues with XCOM, SYNCSORT, FILEAID and ISPW.



Sent from my iPhone

> On Jan 16, 2020, at 9:48 AM, Lennie Dymoke-Bradshaw 
>  wrote:
> 
> I am doing planning for the encryption of application data. I have a need to 
> encrypt some fairly large numbers of VSAM datasets.
> 
> I am trying to develop some tooling to help with the allocation and 
> encryption of the VSAM data sets. I need to define replacement data sets 
> which are extended format (DSNTYPE=EXTREQ in JCL terms). I can allocate new 
> data sets using the following methods,
> 
> 
>  1.  IDCAMS: DEFINE CLUSTER with MODEL pointing at existing cluster. Using 
> this method I can specify the names of the VSAM index and data components. 
> However, I cannot see how to specify that I want extended format.
>  2.  IDCAMS: ALLOCATE with LIKE specifying the original cluster name. Using 
> this method I can specify DSNTYPE(EXTREQ), but I cannot specify the names of 
> the data and index components.
>  3.  IKJEFT01: ALLOCATE with LIKE specifying the original cluster name. This 
> is identical to option 2 as IDCAMS will be invoking IKJEFT01 to do the 
> allocation.
>  4.  JCL: With this method I can again specify DSNTYPE=EXTREQ, but I cannot 
> specify the names of the index and data components.
> 
> At this stage I do not want to alter the existing SMS ACS routines.  Is there 
> any way I can specify both the data and index component names and EXTREQ?
> 
> Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd
> Web:  www.rsmpartners.com
> 'Dance like no one is watching. Encrypt like everyone is.'
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu 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

3270 PCOMM Emulator support for Japanese

[Cameron Conacher]

Hello folks,
Quick question.
Anyone doing support work for Japanese language?
Using PCOMM Emulator sessions?

I have been working at this for twenty+ years.
We used to run EXTRA, and our own home grown emulator sessions.
Now we are running PCOMM.
All I want to be able to do, is have my PCOMM Emulator 3270 sessions
installed so that I can choose configure, and then select Japanese from the
Host Code Page drop down list.
I simply want to have IBM-930 available in the list.
Currently my list shows Italy, and then Latin America; no "J"s at all.

I expected that I could have our support folks run some magic incantation
to have IBM-930 added to my drop down selection list.
I cannot read or write Japanese. I do not want to be able to type Japanese.
I just want to be able to look at some Japanese text in a file, and first
see the Japanese characters, and then second be able to browse the file in
ISPF HEX mode to see the actual underlying hex values.

So far I have had no luck.
Is there anyone here who happens to be a PCOMM resource, and understands
what I need to ask our support folks to do?

Thanks in advance for any advice.

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

Re: Question - UUID Approach for Mainframes in Japan

[Cameron Conacher]

Hello again Leonardo,
I just found this
https://www.ibm.com/support/knowledgecenter/SSSH27_8.0.1/com.ibm.rational.clearcase.cczose.doc/topics/r_cce_ibm930.htm

The first paragraph reads:

*Because IBM-930 does not support lowercase alphabet characters, TSO client
does not support them either.*


So, I guess IBM-930 just does not provide support for lowercase alphabetics.


On Thu, Nov 28, 2019 at 9:56 AM Leonardo Vaz  wrote:

> Wow, thanks for replying, that is interesting and I'd love to know if you
> get to any conclusion. Maybe a feature lack on the emulator you are using,
> the emulator I use doesn't even has IBM-930 so I can't even test it here
> but comes to show that support for that code page may be lacking overall.
>
> Regards,
> Leo
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Cameron Conacher
> Sent: Thursday, November 28, 2019 9:24 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Question - UUID Approach for Mainframes in Japan
>
> Hello Leonardo,
> I am sorry I took so long, but I wanted to get all my ducks in line.
> The link you provided shows lower case English letters with hex values
> x'62'-x'69', x'71'-x'78', x'8B', x'9B', x'AB', and x'B3'-x'B9'.
> I created a small file with all the 256 EBCDIC hex combinations, and
> browsed it after setting my emulator Host CodePage to IBM-930. (IBM PCOM)
> All of the above listed hex values show a blank character displayed.
>
> When I browse the same file after setting my PCOM emulator Host CodePage to
> EBCDIC IBM-037, I see lower case English Letters in hex positions
> x'81'-x'89', x'91'-x'99', and x'A2'-x'A9'.
> These hex positions are occupied by SBCS Katakana characters in the EBCDIC
> CodePage 930 display.
>
> Then I took my little file, and transformed it from IBM-930 to UTF-8.
> When I browse that file as a UTF-8 encoded file, I can see lower case
> English letters.
>
> I hope this all makes some sense to you.
> I tried to be as diligent as possible in gathering the information.
>
> What this actually means is a bit beyond me. Characters really are
> converted as per the chart, but never displayed... hm.
> I think that the emulator may be doing something, or perhaps something
> happens within the 3270 datastream.
> In any event,my emulator does not render any displayable characters for the
> hex positions indicated by the lower case English values, as if they do not
> exist.
>
> This is interesting. And I need to do some more thinking on this, but I
> already have an approach to deal with the UUID as per Charles and Attila.
>
> Thanks
>
> On Mon, Nov 25, 2019 at 4:05 PM Leonardo Vaz  wrote:
>
> > Hello Cameron!
> >
> > I see all lowercase letters on
> > http://demo.icu-project.org/icu-bin/convexp?conv=ibm-930.
> >
> > Why do you say there is no support?
> >
> > Regards,
> > Leo
> >
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Cameron Conacher
> > Sent: Monday, November 25, 2019 3:43 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Question - UUID Approach for Mainframes in Japan
> >
> > Hello folks,
> > I am here with another question today.
> > We are a large international company with a market presence in Japan.
> > We store our mainframe EBCDIC data for these markets in EBCDIC CodePage
> > 930.
> > This CodePage has no support for lower case English letters.
> >
> > If I were a distributed platform and I generated a UTF-8 encoded UUID
> > value, and sent this value to the mainframe, it would be then transformed
> > into EBCDIC CodePage 930.
> > If the UUID were to be generated with any lower case English values ("a",
> > "b", "c", "d", "e", or "f") I would expect to encounter some issue at
> > conversion/transformation time, since the underlying EBCDIC CodePage
> cannot
> > support the value.
> > However, if upper case values were sent instead ("A", "B", "C", "D", "E",
> > or "F"), everything would flow and transform politely.
> >
> > So, my question is whether in the Japan world, mainframe application
> expect
> > Consumers to send only upper cased values, or if an intermediate step
> prior
> > to message transformation occurs close to the mainframe side of things to
> > force upper casing of the UUID.
> > Or some other technique?
> > Similarly, if a UUID were to be sent from the mainframe to the middle
> tier
> > somewhere, should I expect

Re: Question - UUID Approach for Mainframes in Japan

[Cameron Conacher]

Hello Leonardo,
I am sorry I took so long, but I wanted to get all my ducks in line.
The link you provided shows lower case English letters with hex values
x'62'-x'69', x'71'-x'78', x'8B', x'9B', x'AB', and x'B3'-x'B9'.
I created a small file with all the 256 EBCDIC hex combinations, and
browsed it after setting my emulator Host CodePage to IBM-930. (IBM PCOM)
All of the above listed hex values show a blank character displayed.

When I browse the same file after setting my PCOM emulator Host CodePage to
EBCDIC IBM-037, I see lower case English Letters in hex positions
x'81'-x'89', x'91'-x'99', and x'A2'-x'A9'.
These hex positions are occupied by SBCS Katakana characters in the EBCDIC
CodePage 930 display.

Then I took my little file, and transformed it from IBM-930 to UTF-8.
When I browse that file as a UTF-8 encoded file, I can see lower case
English letters.

I hope this all makes some sense to you.
I tried to be as diligent as possible in gathering the information.

What this actually means is a bit beyond me. Characters really are
converted as per the chart, but never displayed... hm.
I think that the emulator may be doing something, or perhaps something
happens within the 3270 datastream.
In any event,my emulator does not render any displayable characters for the
hex positions indicated by the lower case English values, as if they do not
exist.

This is interesting. And I need to do some more thinking on this, but I
already have an approach to deal with the UUID as per Charles and Attila.

Thanks

On Mon, Nov 25, 2019 at 4:05 PM Leonardo Vaz  wrote:

> Hello Cameron!
>
> I see all lowercase letters on
> http://demo.icu-project.org/icu-bin/convexp?conv=ibm-930.
>
> Why do you say there is no support?
>
> Regards,
> Leo
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Cameron Conacher
> Sent: Monday, November 25, 2019 3:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Question - UUID Approach for Mainframes in Japan
>
> Hello folks,
> I am here with another question today.
> We are a large international company with a market presence in Japan.
> We store our mainframe EBCDIC data for these markets in EBCDIC CodePage
> 930.
> This CodePage has no support for lower case English letters.
>
> If I were a distributed platform and I generated a UTF-8 encoded UUID
> value, and sent this value to the mainframe, it would be then transformed
> into EBCDIC CodePage 930.
> If the UUID were to be generated with any lower case English values ("a",
> "b", "c", "d", "e", or "f") I would expect to encounter some issue at
> conversion/transformation time, since the underlying EBCDIC CodePage cannot
> support the value.
> However, if upper case values were sent instead ("A", "B", "C", "D", "E",
> or "F"), everything would flow and transform politely.
>
> So, my question is whether in the Japan world, mainframe application expect
> Consumers to send only upper cased values, or if an intermediate step prior
> to message transformation occurs close to the mainframe side of things to
> force upper casing of the UUID.
> Or some other technique?
> Similarly, if a UUID were to be sent from the mainframe to the middle tier
> somewhere, should I expect that the mainframe would only pas along upper
> cased values in the UUID area?
>
> I believe I can handle things on the mainframe side by transforming the
> entire message to UTF-16BE, and then upper casing the UUID, and then
> transforming this updated UTF-16BE message area to EBCDIC CodePage 930.
> Not sure if this is a "good" way, but it would work.
>
> Any thoughts?
>
> Thanks
>
> ...Cameron
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu 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: Question - UUID Approach for Mainframes in Japan

[Cameron Conacher]

Thanks everyone
This is great.

Sent from my iPhone

> On Nov 26, 2019, at 5:23 PM, Charles Mills  wrote:
> 
> Yeah, sorry, I fully admit I have zero real-world experience with UUIDs on Z 
> -- Japanese or otherwise. And relatively little elsewhere: I have used them 
> for version signing on Visual Studio -- that's it.
> 
> I would certainly think (hope!) that any reasonable code would be using the 
> underlying 128-bit binary value, and whether you used abc, ABC or some 
> mixture would be irrelevant.
> 
> I think the standard is pretty clear: the 128-bit binary value *is* the UUI, 
> the character string is just a representation thereof, and upper-case hex 
> values are acceptable.
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Cameron Conacher
> Sent: Tuesday, November 26, 2019 9:00 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Question - UUID Approach for Mainframes in Japan
> 
> Thanks Charles,
> I was hoping someone with a Japan background would weigh in to say
> something along the lines of "have the Consumers upper case the UUID BEFORE
> they send it to you" or, "we use DATAPOWER to force upper case on all UUIDs
> BEFORE the strings arrive in the mainframe". or something else.
> 
> If a Consumer were to send me a UUID in Lower Case and I return a reply
> with the UUID Upper Cased, does this cause some inconsistency on the
> Consumer's side of the fence?
> I mean, functionally, the UUIDs are the same, but the actual string values
> are different.
> Does this create issues?
> 
> 
>> On Mon, Nov 25, 2019 at 4:30 PM Charles Mills  wrote:
>> 
>> UUID letters as generated are all lower case, so you could translate them
>> to upper case without losing any information.
>> 
>> Anything that accepts UUIDs must be prepared to accept upper case, so you
>> would be good to go.
>> 
>> -- https://tools.ietf.org/html/rfc4122#section-3
>> 
>> Charles
>> 
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Cameron Conacher
>> Sent: Monday, November 25, 2019 3:43 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Question - UUID Approach for Mainframes in Japan
>> 
>> Hello folks,
>> I am here with another question today.
>> We are a large international company with a market presence in Japan.
>> We store our mainframe EBCDIC data for these markets in EBCDIC CodePage
>> 930.
>> This CodePage has no support for lower case English letters.
>> 
>> If I were a distributed platform and I generated a UTF-8 encoded UUID
>> value, and sent this value to the mainframe, it would be then transformed
>> into EBCDIC CodePage 930.
>> If the UUID were to be generated with any lower case English values ("a",
>> "b", "c", "d", "e", or "f") I would expect to encounter some issue at
>> conversion/transformation time, since the underlying EBCDIC CodePage cannot
>> support the value.
>> However, if upper case values were sent instead ("A", "B", "C", "D", "E",
>> or "F"), everything would flow and transform politely.
>> 
>> So, my question is whether in the Japan world, mainframe application expect
>> Consumers to send only upper cased values, or if an intermediate step prior
>> to message transformation occurs close to the mainframe side of things to
>> force upper casing of the UUID.
>> Or some other technique?
>> Similarly, if a UUID were to be sent from the mainframe to the middle tier
>> somewhere, should I expect that the mainframe would only pas along upper
>> cased values in the UUID area?
>> 
>> I believe I can handle things on the mainframe side by transforming the
>> entire message to UTF-16BE, and then upper casing the UUID, and then
>> transforming this updated UTF-16BE message area to EBCDIC CodePage 930.
>> Not sure if this is a "good" way, but it would work.
>> 
>> Any thoughts?
>> 
>> Thanks
>> 
>> ...Cameron
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the messag

Re: Question - UUID Approach for Mainframes in Japan

[Cameron Conacher]

Thanks Charles,
I was hoping someone with a Japan background would weigh in to say
something along the lines of "have the Consumers upper case the UUID BEFORE
they send it to you" or, "we use DATAPOWER to force upper case on all UUIDs
BEFORE the strings arrive in the mainframe". or something else.

If a Consumer were to send me a UUID in Lower Case and I return a reply
with the UUID Upper Cased, does this cause some inconsistency on the
Consumer's side of the fence?
I mean, functionally, the UUIDs are the same, but the actual string values
are different.
Does this create issues?


On Mon, Nov 25, 2019 at 4:30 PM Charles Mills  wrote:

> UUID letters as generated are all lower case, so you could translate them
> to upper case without losing any information.
>
> Anything that accepts UUIDs must be prepared to accept upper case, so you
> would be good to go.
>
> -- https://tools.ietf.org/html/rfc4122#section-3
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Cameron Conacher
> Sent: Monday, November 25, 2019 3:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Question - UUID Approach for Mainframes in Japan
>
> Hello folks,
> I am here with another question today.
> We are a large international company with a market presence in Japan.
> We store our mainframe EBCDIC data for these markets in EBCDIC CodePage
> 930.
> This CodePage has no support for lower case English letters.
>
> If I were a distributed platform and I generated a UTF-8 encoded UUID
> value, and sent this value to the mainframe, it would be then transformed
> into EBCDIC CodePage 930.
> If the UUID were to be generated with any lower case English values ("a",
> "b", "c", "d", "e", or "f") I would expect to encounter some issue at
> conversion/transformation time, since the underlying EBCDIC CodePage cannot
> support the value.
> However, if upper case values were sent instead ("A", "B", "C", "D", "E",
> or "F"), everything would flow and transform politely.
>
> So, my question is whether in the Japan world, mainframe application expect
> Consumers to send only upper cased values, or if an intermediate step prior
> to message transformation occurs close to the mainframe side of things to
> force upper casing of the UUID.
> Or some other technique?
> Similarly, if a UUID were to be sent from the mainframe to the middle tier
> somewhere, should I expect that the mainframe would only pas along upper
> cased values in the UUID area?
>
> I believe I can handle things on the mainframe side by transforming the
> entire message to UTF-16BE, and then upper casing the UUID, and then
> transforming this updated UTF-16BE message area to EBCDIC CodePage 930.
> Not sure if this is a "good" way, but it would work.
>
> Any thoughts?
>
> Thanks
>
> ...Cameron
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu 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

Question - UUID Approach for Mainframes in Japan

[Cameron Conacher]

Hello folks,
I am here with another question today.
We are a large international company with a market presence in Japan.
We store our mainframe EBCDIC data for these markets in EBCDIC CodePage 930.
This CodePage has no support for lower case English letters.

If I were a distributed platform and I generated a UTF-8 encoded UUID
value, and sent this value to the mainframe, it would be then transformed
into EBCDIC CodePage 930.
If the UUID were to be generated with any lower case English values ("a",
"b", "c", "d", "e", or "f") I would expect to encounter some issue at
conversion/transformation time, since the underlying EBCDIC CodePage cannot
support the value.
However, if upper case values were sent instead ("A", "B", "C", "D", "E",
or "F"), everything would flow and transform politely.

So, my question is whether in the Japan world, mainframe application expect
Consumers to send only upper cased values, or if an intermediate step prior
to message transformation occurs close to the mainframe side of things to
force upper casing of the UUID.
Or some other technique?
Similarly, if a UUID were to be sent from the mainframe to the middle tier
somewhere, should I expect that the mainframe would only pas along upper
cased values in the UUID area?

I believe I can handle things on the mainframe side by transforming the
entire message to UTF-16BE, and then upper casing the UUID, and then
transforming this updated UTF-16BE message area to EBCDIC CodePage 930.
Not sure if this is a "good" way, but it would work.

Any thoughts?

Thanks

...Cameron

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