SFTP question

[Peter]

Hello

Cross posted

I am trying to send dataset to a Linux server which has a SFTP running on
it. Is it possible to connect the Linux servers SFTP using mainframe JCL to
put or get the file from Linux ?

Peter

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

Re: Automation of the TSO RECEIVE command

[Paul Gilmartin]

On Thu, 1 Sep 2022 08:47:39 +0800, Peter Van Dyke wrote:
>
>Here's an example of the JCL for the job:
>/*...
>//*
>//XMIT01 DD   DATA,DLM='@%'
>*- Data created by XMIT for data set 1 -*
> 
How do you ensure that the XMIT data does not contain '@%' in columns 1-2?

Long ago, I experimented with uuencode to further encode the XMIT output
and using a DLM that uuencode can not create.  It worked; I never used it
in practice.

-- 
gil

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

Re: Automation of the TSO RECEIVE command

[Peter Van Dyke]

Hi,
I'm not sure if this meets your needs but when I have to send data sets in
XMIT format to customers I'll create a job containing the XMIT data and TSO
RECEIVE commands and send that to the customer, for example as an email
attachment.
Here's an example of the JCL for the job:

//XMIT0001 JOB (),'DUMMY',MSGCLASS=X,CLASS=A,
// NOTIFY=
//*
//STEP1 EXEC PGM=IKJEFT01,DYNAMNBR=16
//SYSTSPRT  DD   SYSOUT=*
//SYSTSIN   DD   *

  DELETE 'HLQ.XMIT.DATA1'
  DELETE 'HLQ.XMIT.DATA2'

  RECEIVE INDD(XMIT01))
DS('HLQ.XMIT.DATA1') NEW

  RECEIVE INDD(XMIT02))
DS('HLQ.XMIT.DATA2') NEW
/*
//*
//XMIT01 DD   DATA,DLM='@%'
*- Data created by XMIT for data set 1 -*

@%
//XMIT02DD   DATA,DLM='@%'
*- Data created by XMIT for data set 2 -*

@%

The customer uploads the file in binary format to an LRECL 80 data set or
member. All they then have to do is change the data set names in STEP1 and
possibly the job card then submit the job to receive the data sets.

I hope that helps.

Regards,
Peter Van Dyke

On Thu, 1 Sept 2022 at 07:34, Lennie Dymoke-Bradshaw <
032fff1be9b4-dmarc-requ...@listserv.ua.edu> wrote:

> Gil,
>
> Yes, you're right.
> I have in the past I have scanned the card image file before sending and
> then built JCL which uses a DLM value which is OK.
> Lennie
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Paul Gilmartin
> Sent: 31 August 2022 13:56
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Automation of the TSO RECEIVE command
>
> On Wed, 31 Aug 2022 11:12:12 +0100, Lennie Dymoke-Bradshaw wrote:
>
> >The TSO commands TRANSMIT and RECEIVE are very useful for moving data
> >around, particularly as TRANSMIT produces an 80-byte LRECL which works
> >easily with in-stream JCL.
> >
> But there's a hazard.  The encoded data might by happenstance contain "//"
> in the first two positions of a record, breaking the in-stream data set.
> You can demonstrate this by TRANSMITting a file containing many "/"
> characters.
>
> It's safer if you use "DATA,DLM='U5ZMw0Di'", for example in JES2.  In
> JES3, you're SOL.
>
> ( I used "head -c6 /dev/random | uuencode -m x".)
>
> --
> gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Automation of the TSO RECEIVE command

[Lennie Dymoke-Bradshaw]

Gil,

Yes, you're right. 
I have in the past I have scanned the card image file before sending and then 
built JCL which uses a DLM value which is OK.
Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: 31 August 2022 13:56
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Automation of the TSO RECEIVE command

On Wed, 31 Aug 2022 11:12:12 +0100, Lennie Dymoke-Bradshaw wrote:

>The TSO commands TRANSMIT and RECEIVE are very useful for moving data 
>around, particularly as TRANSMIT produces an 80-byte LRECL which works 
>easily with in-stream JCL.
> 
But there's a hazard.  The encoded data might by happenstance contain "//" in 
the first two positions of a record, breaking the in-stream data set.  You can 
demonstrate this by TRANSMITting a file containing many "/" characters.

It's safer if you use "DATA,DLM='U5ZMw0Di'", for example in JES2.  In JES3, 
you're SOL.

( I used "head -c6 /dev/random | uuencode -m x".)

--
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: Automation of the TSO RECEIVE command

[Matthew Stitt]

Interesting The next line was there when I copied it:


PROFILE NOPROMPT NOPREFIX  
RECEIVE INDA('MSTITT.IBM.HHOP850.F1.BIN')  
DATASET('MSTITT.HHOP850.F1')   

Matthew

On Wed, 31 Aug 2022 13:43:22 -0500, Paul Gilmartin  wrote:

>On Wed, 31 Aug 2022 13:22:28 -0500, Matthew Stitt wrote:
>
>>Here is a snippet from my JCL:
>>
>>//TSO EXEC PGM=IKJEFT01,DYNAMNBR=20
>>//SYSTSPRT DD  SYSOUT=*
>>//SYSPROC  DD  DSN=MSTITT.CLIST,DISP=SHR   
>>//SYSTSIN  DD  *   
>>PROFILE NOPROMPT NOPREFIX  
>>RECEIVE INDA('MSTITT.IBM.HHOP850.F1.BIN')  
>>
>Show the next line in your SYSTSIN.  It probably matters.  The Ref. says:
>
>RECEIVE command prompt parameters
>After describing each file, the RECEIVE command prompts for overriding 
> parameters.
>These parameters are all optional and control the restoring of the 
> data set. Parameters
>not specified are allowed to default or are taken from information 
> transmitted with the data.
>The optional parameters are shown below.
>
>"parameters are all optional".  So it's permitted to provide no parameters.  
>In that case,
>does RECEIVE expect an empty line in response to the prompt?  What is the 
>effect if
>there is no such line?
>
>Most users will choose to specify DSNAME rather than taking the default.
>
>-- 
>gil
>

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

Re: Automation of the TSO RECEIVE command

[Tony Harminc]

On Wed, 31 Aug 2022 at 06:14, Lennie Dymoke-Bradshaw <
032fff1be9b4-dmarc-requ...@listserv.ua.edu> wrote:

> The TSO commands TRANSMIT and RECEIVE are very useful for moving data
> around, particularly as TRANSMIT produces an 80-byte LRECL which works
> easily with in-stream JCL.
>
> But has anyone worked out a reliable mechanism to automate the use of the
> RECEIVE command?
>

I doubt that there is any reliable method. There can almost always be an
unexpected prompt.


> It always issues queries to the user. How can the responses to these
> queries
> be simply handled?
>
> I feel sure someone has worked this out.
>

RECEIVE is not the only program that understands the format written by XMIT
et al. For instance there is https://www.cbttape.org/ftp/cbt/CBT571.zip
that provides a compatible program that doesn't prompt (most people run it
in batch, but it works under TSO too, of course), and generally doesn't
require APF authorization.

Tony H.

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

Re: ELAX DRAWDOWN??

[Joe Monk]

Isnt ELAX IBM rational products?

Joe

On Wed, Aug 31, 2022 at 9:04 AM Steve Thompson  wrote:

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

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

Re: Automation of the TSO RECEIVE command

[Willy Jensen]

You can pull the information from the XMIT dataset and then either present it 
to the user in a dialog, or act upon it directly.
Here is a snippet that 'says' the original datasetname and user..

  /* get xmit datasetname */
  arg inda  
  say 'xmitda='inda 

  /* get xmit data */   
  queue 'END'   
  Call DoReceive
  parse var resp.1 xmsg . srcds . srcuser . 
  say 'srcds='srcds 
  say 'srcuser='srcuser 
  exit 0

 DoReceive: 
  p=prompt('on')
  zz=outtrap('resp.')   
  "receive inda("inda")"
  cc=rc 
  zz=outtrap('off') 
  p=prompt(p)   
  if cc<>0 then do n=1 to resp.0
say resp.n  
  end   
  return cc 

 Silent: zz=outtrap(word(arg(2) '$.',1))
 address tso arg(1);zz=outtrap('off');return rc

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

Re: ELAX DRAWDOWN??

[Sri h Kolusu]

>> ELAX DRAWDOWN??  Any one heard of this or what it is?

Steve,

Perhaps Enterprise Software Management Tool (ESMT) for tracking your license 
draw-downs?

https://www.ibm.com/client-tools/esmt


Thanks,
Kolusu


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

Re: ELAX DRAWDOWN??

[Tony Harminc]

On Wed, 31 Aug 2022 at 10:04, Steve Thompson  wrote:

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

Sounds like a character in a novel or movie. Elax Drawdown, the new sheriff
of Z-ville. Along with his trusty sidekick Bitwise Leftshift, he'll round
up those Little Endians and page them all out!

Tony H.

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

Re: Network issues at Dallas RDP site?

[Tony Tancredi]

It's been down most of the day. Weird thing is their domain name: 
dtsc.dfw.ibm.com, doesn't even resolve through DNS. I guess they host their own 
DNS servers in the same environment.

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

Network issues at Dallas RDP site?

[Sean Gleann]

(Possible repeat - not sure if my previous response got through...)



We received email from RDP timestamped 03:07UTC:

"Due to required maintenance, the remote development environment is
temporarily unavailable.
We are working as quickly as we can to restore services, please be patient
and we will update you as soon as possible."

Nothing new since then.
Have not been able to do any work on our z/OS systems at all today

Sean

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

Re: Calculate deltas using DFSORT

[Paul Gilmartin]

On Wed, 31 Aug 2022 13:30:14 -0500, Walt Farrell wrote:
>
>But, whose "tradition"? PERL, PCRE, Python, Boost, ...
>
Don't overlook .

-- 
gil

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

Re: Network issues at Dallas RDP site?

[Sean Gleann]

We received email from RDP timestamped 03:07UTC:

"Due to required maintenance, the remote development environment is
temporarily unavailable.
We are working as quickly as we can to restore services, please be patient
and we will update you as soon as possible."

Nothing new since then.
Have not been able to do any work on our z/OS systems at all today

Sean



On Wed, 31 Aug 2022 at 19:18, Farley, Peter x23353 <
031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:

> The IBM Zxplore systems at the Dallas RDP site are unreachable (the
> Zxplore website says "network issues").
>
> Has anyone heard anything about what those issues may be?
>
> 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
>

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

Re: Calculate deltas using DFSORT

[Paul Gilmartin]

On Wed, 31 Aug 2022 13:30:14 -0500, Walt Farrell wrote:
>
>>But it might be proper to emphasize any difference between DFSORT's use of
>>reg-ex and traditional beliefs.
>
>But, whose "tradition"? PERL, PCRE, Python, Boost, ...
>
>Does the DFSORT documentation name a standard that they've implemented?
>
Several.  "The great thing about standards ...".  From the Guide:
Regular expressions
This support is based on the following Standards /Extensions:
• XPG4 (X/Open Common Applications Environment Specification, System Interfaces 
and Headers, Issue 4.)
• XPG4.2 (X/Open Common Applications Environment Specification, System 
Interfaces and Headers, Issue 4, Version 2.)
• Single UNIX Specification, Version 3 (IEEE Std 1003.1-2001.)
• z/OS UNIX (functions that provide z/OS UNIX support beyond the defined 
standards.)
Two versions of regular expressions are supported:
• Basic Regular expressions (BRE)
• Extended Regular expressions (ERE)

I don't see where the Guide tells how the programmer may choose between BRE and 
ERE.
(But it does provide the REH extension.)

They didn't mention XLC/C++, probably the underlying support.

-- 
Thanks,
gil

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

Re: Automation of the TSO RECEIVE command

[Paul Gilmartin]

On Wed, 31 Aug 2022 13:22:28 -0500, Matthew Stitt wrote:

>Here is a snippet from my JCL:
>
>//TSO EXEC PGM=IKJEFT01,DYNAMNBR=20
>//SYSTSPRT DD  SYSOUT=*
>//SYSPROC  DD  DSN=MSTITT.CLIST,DISP=SHR   
>//SYSTSIN  DD  *   
>PROFILE NOPROMPT NOPREFIX  
>RECEIVE INDA('MSTITT.IBM.HHOP850.F1.BIN')  
>
Show the next line in your SYSTSIN.  It probably matters.  The Ref. says:

RECEIVE command prompt parameters
After describing each file, the RECEIVE command prompts for overriding 
parameters.
These parameters are all optional and control the restoring of the data 
set. Parameters
not specified are allowed to default or are taken from information 
transmitted with the data.
The optional parameters are shown below.

"parameters are all optional".  So it's permitted to provide no parameters.  In 
that case,
does RECEIVE expect an empty line in response to the prompt?  What is the 
effect if
there is no such line?

Most users will choose to specify DSNAME rather than taking the default.

-- 
gil

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

Re: Calculate deltas using DFSORT

[Walt Farrell]

On Wed, 31 Aug 2022 11:13:57 -0500, Paul Gilmartin  wrote:


>>In any case, "[^abc]" does not match "wombat". It matches only a single 
>>character of a string. So, it might match the "w" in "wombat", or the "o", or 
>>the "m", or the "t", depending on other details of the input string being 
>>processed, and the application doing the processing.
>> 
>Absent an anchor ("^" and/or "$") a pattern can be matched anywhere in a 
>subject.

Good point. Thanks.

>
>>I agree with your comment (which I omitted from my quote) that the DFSORT 
>>books should not try to explain reg-ex processing, unless they have written 
>>their own processor instead of reusing someone else's.
>>
>+1
>But it might be proper to emphasize any difference between DFSORT's use of
>reg-ex and traditional beliefs.

But, whose "tradition"? PERL, PCRE, Python, Boost, ...

Does the DFSORT documentation name a standard that they've implemented?

-- 
Walt

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

Re: Calculate deltas using DFSORT

[Walt Farrell]

On Wed, 31 Aug 2022 16:35:27 +, Sri h Kolusu  wrote:


>>>The DFSORT manual (and others) should not attempt to explain regular 
>>>expressions.  They should defer to citing a single publication with such an 
>>>explanation.
>
>I completely agree, however each component within IBM is implementing a 
>regular expression flavor. Different regular expression flavors are not fully 
>compatible with each other. So it is difficult to have 1 central publication.

Perhaps, if you're implementing a specific, standard reg-ex flavor (e.g., PERL, 
or PCRE, or one of the Boost libraries) you could consider just pointing to the 
standard documentation. You would then only need to document exceptions to the 
standard behavior.

-- 
Walt

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

Re: Automation of the TSO RECEIVE command

[Paul Gilmartin]

On Wed, 31 Aug 2022 12:26:11 -0500, Steve Horein wrote:
>
>> 
>
>It's safer if you use "DATA,DLM='U5ZMw0Di'", for example in JES2.  In JES3,
>> you're SOL.
>>
>> ( I used "head -c6 /dev/random | uuencode -m x".)
>
>What leads you to believe DATA or DLM is unacceptable with JES3?
>I use it quite extensively.
>
From the Ref.:
Subparameter definition
delimiter
Specifies 2 characters in a JES3 environment and 2 to 8 in a JES2 
environment
that indicates the end of this data set in the input stream.

Would my example above work in a JES3 system?  Two isn't enough.

-- 
gil

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

Re: Automation of the TSO RECEIVE command

[Matthew Stitt]

Here is a snippet from my JCL:

//TSO EXEC PGM=IKJEFT01,DYNAMNBR=20
//SYSTSPRT DD  SYSOUT=*
//SYSPROC  DD  DSN=MSTITT.CLIST,DISP=SHR   
//SYSTSIN  DD  *   
PROFILE NOPROMPT NOPREFIX  
RECEIVE INDA('MSTITT.IBM.HHOP850.F1.BIN')  

On Wed, 31 Aug 2022 18:15:16 +, Seymour J Metz  wrote:

>You put the necessary response in the stack. The details depend on whether you 
>are using CLIST or REXX.
>
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>Lennie Dymoke-Bradshaw [032fff1be9b4-dmarc-requ...@listserv.ua.edu]
>Sent: Wednesday, August 31, 2022 6:12 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Automation of the TSO RECEIVE command
>
>The TSO commands TRANSMIT and RECEIVE are very useful for moving data
>around, particularly as TRANSMIT produces an 80-byte LRECL which works
>easily with in-stream JCL.
>
>But has anyone worked out a reliable mechanism to automate the use of the
>RECEIVE command?
>
>It always issues queries to the user. How can the responses to these queries
>be simply handled?
>
>I feel sure someone has worked this out.
>
>
>Lennie Dymoke-Bradshaw
>

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

Re: Calculate deltas using DFSORT

[Seymour J Metz]

"Give a man a fish and you feed him for a day. Teach him to fish and you feed 
him for life."

An explanation is better than an example in the long run, although ideally you 
get both.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom 
Brennan [t...@tombrennansoftware.com]
Sent: Wednesday, August 31, 2022 12:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Calculate deltas using DFSORT

But with DFSORT I don't need to know the syntax at all.  I can post a
note here describing what I'm trying to do along with some data samples,
and like the elves who make shoes, complete JCL and SYSIN will magically
appear the next morning.

On 8/30/2022 5:02 PM, Paul Gilmartin wrote:

> The DFSORT command syntax is dreadful -- too positional.  It's
> hard to read ...,keyword,value,keyword,value,...
> Considerably better would be ,keyword(value), or ,keyword=value,...
> I suppose the design is OK to programmers versed in it, but it
> repels the novice.  It may be easy for a computer to parse,
> but silicon is now cheaper than carbon.

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

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

Network issues at Dallas RDP site?

[Farley, Peter x23353]

The IBM Zxplore systems at the Dallas RDP site are unreachable (the Zxplore 
website says "network issues").

Has anyone heard anything about what those issues may be?

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

Re: Automation of the TSO RECEIVE command

[Seymour J Metz]

You put the necessary response in the stack. The details depend on whether you 
are using CLIST or REXX.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Lennie Dymoke-Bradshaw [032fff1be9b4-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, August 31, 2022 6:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Automation of the TSO RECEIVE command

The TSO commands TRANSMIT and RECEIVE are very useful for moving data
around, particularly as TRANSMIT produces an 80-byte LRECL which works
easily with in-stream JCL.

But has anyone worked out a reliable mechanism to automate the use of the
RECEIVE command?

It always issues queries to the user. How can the responses to these queries
be simply handled?

I feel sure someone has worked this out.





Lennie Dymoke-Bradshaw

https://secure-web.cisco.com/1HXqNOLrKkewNKi0OrUOf4MFsZJVR0avNQuZ0dkcuhdQvrBEp1sI4T5llyKJf9ZtIVb6msrUBL5gEQ-aOKOrXkpM8O_28o3lWYjKQ1lFLxSpuMhh55LNtloIDD68yTQknrM9fDeCYnjovfRyAx6awq055rUJSqQvj6ps08olWJxOA4O5pDEpQNqiuNpEMyFUDmXEeiaYBzzhAKvV5nSwmpt0JkgGP3yZkGD44TmmEs34hA0C7tWFa3vEeIMqQO2lvE1yhYtmOxzGPOMXf1xvlW3bYIAxsDR3j_s7NCFtHb617kJnaGQNgMZKnZNgYisxA7GcdSW0297yzSwXf4VKhaLzzs9siQLJiBOkyOK2H6l9ZDuxIKrUDmZ_vBlsEvLpak_A3E-jorZQCPsJ9ihyL7mJbYOEyzxUJ6LHHK6n8yZZwiPQbIYxyLTG_h0sqg4c3/https%3A%2F%2Frsclweb.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

Re: Calculate deltas using DFSORT

[Seymour J Metz]

The not character for character classes in Unix regexen is Caret (^) rather 
than Logical Not (¬). I believes that this stems from an era when ASCII was in 
a state of flux and one code point could be either ^ or ¬.

And, yes, [^string] matches a single character not containing an character in 
string. Contrast with

 [^string]?
 [^string]*
 [^string]+

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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, August 31, 2022 11:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Calculate deltas using DFSORT

On Wed, 31 Aug 2022 05:55:46 -0500, Mario Bezzi wrote:

>Sri Hari, Max, all,
>
>thank you very much from your kind help and support.
>
>I really appreciate it, and I hope to have the opportunity to reciprocate.
>
+1
Kolusu's assistance is priceless!


I've read on about regular expressions.  I see in the DFSORT Guide:
INCLUDE Control Statement
  The basic regular expression metacharacters are:
 ¬ $ . * \( \) [ \{ \} \

but later in a table:
[^string]

Is it "^" or "¬"?  Some clarification is needed.  I'll submit an RCF.

I hate EBCDIC!

The ISPF Edit Macros manual says that  metacharacters in regular
expressions are interpreted according to the CCSID of the controlling
terminal, listing several dozen supported CCSIDs, and says that in
background IBM-1047 is presumed.  Is this also true if DFSORT is
invoked by TSO CALL?  If SYSIN is allocated to a UNIX file tagged
with a CCSID, does DFSORT respect that CCSID?

I hate EBCDIC!

Also, in a table:
The caret symbol, when inside square brackets,
negates the characters within the square brackets.
Thus [^abc], if compared to other strings, would fail
to match any that contains even one a, b, or c.

("when inside square brackets" seems to be a restrictive
clause.  It should not be enclosed in commas.)

The "^" must be the first character inside the brackets
to have this effect.

The last sentence beginning "Thus ..." is incorrect.

"[^abc]" matches any string containing a character
other than a, b, or c.  It matches "wombat".  However,
"^[^abc]*$" matches strings containing no character
other than a, b, or c.   It does not match "wombat".

Another RCF, or the same one?

The DFSORT manual (and others) should not attempt
to explain regular expressions.  They should defer to
citing a single publication with such an explanation.

--
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: Calculate deltas using DFSORT

[Carmen Vitullo]

+1 Tom, in my experience getting tradition help here has been great, 
especially in the DFSORT area, in my experience getting help with Java 
related issues, even from my vendors was spurratic(sp)  at best


Carmen

On 8/31/2022 12:30 PM, Tom Brennan wrote:

On 8/31/2022 9:35 AM, Sri h Kolusu wrote:
I can post a note here describing what I'm trying to do along with 
some data samples, and like the elves who make shoes, complete JCL 
and SYSIN will magically appear the next morning.


Tom,

I believe this platform is to share and help each other. I for one 
believe in sharing the knowledge and in the process, I might learn a 
thing or two from other topics. It also helps us to understand the 
customer requirements and implement them in future.There may be few 
bad apples who might take advantage of the help being received here, 
but that shouldn't stop us from sharing the knowledge.




I don't know how this turned into something about helping and sharing. 
I'm saying that if I don't know how to work either DFSORT or Java, I'd 
choose DFSORT because I'd get much better help here, often including 
complete and tested JCL/SYSIN.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: 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: Calculate deltas using DFSORT

[Tom Brennan]

On 8/31/2022 9:35 AM, Sri h Kolusu wrote:

I can post a note here describing what I'm trying to do along with some data 
samples, and like the elves who make shoes, complete JCL and SYSIN will 
magically appear the next morning.


Tom,

I believe this platform is to share and help each other. I for one believe in 
sharing the knowledge and in the process, I might learn a thing or two from 
other topics. It also helps us to understand the customer requirements and 
implement them in future.There may be few bad apples who might take advantage 
of the help being received here, but that shouldn't stop us from sharing the 
knowledge.



I don't know how this turned into something about helping and sharing. 
I'm saying that if I don't know how to work either DFSORT or Java, I'd 
choose DFSORT because I'd get much better help here, often including 
complete and tested JCL/SYSIN.


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

Re: Automation of the TSO RECEIVE command

[Steve Horein]

On Wed, Aug 31, 2022 at 7:56 AM Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:


> 

It's safer if you use "DATA,DLM='U5ZMw0Di'", for example in JES2.  In JES3,
> you're SOL.
>
> ( I used "head -c6 /dev/random | uuencode -m x".)
>
> --
> gil
>

What leads you to believe DATA or DLM is unacceptable with JES3?
I use it quite extensively.

On Wed, Aug 31, 2022 at 7:56 AM Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 31 Aug 2022 11:12:12 +0100, Lennie Dymoke-Bradshaw wrote:
>
> >The TSO commands TRANSMIT and RECEIVE are very useful for moving data
> >around, particularly as TRANSMIT produces an 80-byte LRECL which works
> >easily with in-stream JCL.
> >
> But there's a hazard.  The encoded data might by happenstance contain "//"
> in
> the first two positions of a record, breaking the in-stream data set.  You
> can
> demonstrate this by TRANSMITting a file containing many "/" characters.
>
> It's safer if you use "DATA,DLM='U5ZMw0Di'", for example in JES2.  In JES3,
> you're SOL.
>
> ( I used "head -c6 /dev/random | uuencode -m x".)
>
> --
> 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: CA-11

[Chuck Kreiter]

In a previous role, we replaced CA-11 with Encore from Cybermation (now
CA/Broadcom).

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Steve Beaver
Sent: Wednesday, August 31, 2022 11:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CA-11

Does anyone know a replacement for CA-11?


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: 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: IDC3009I & IDC1566I with a weird dsn

[Jack Zukt]

Hi Mark,

Thank you fr the additional input
Regards
Jack

On Wed, 31 Aug 2022 at 17:35, Steely.Mark  wrote:

> This is what I used for the SYSIN:
>
> //SYSINDD  *
> CMD=DELBCSR;XXX.DSNCPY.X  ;
> /*
> //
> //* NOTE: DSN MUST BE 44 CHARACTERS PADDED WITH BLANKS
>
> For some reason it took me a long time to figure out the DSN format for
> the DELBCSR command.
>
> Warning:  Use at you own risk
>
> Thanks
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Jack Zukt
> Sent: Wednesday, August 31, 2022 11:25 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IDC3009I & IDC1566I with a weird dsn
>
> ATTENTION: This e-mail came from an external source. Do not open
> attachments or click on links from unknown or unexpected emails.
>
>
> Hi Mark,
>
> Thank you for the suggestion.
> There is FIXVVDS on SYS1.LINKLIB with a description on SYS1.SAMPLIB. I am
> going to read and maybe give it a try.
> Regards
> Jack
>
> On Wed, 31 Aug 2022 at 17:01, Steely.Mark 
> wrote:
>
> > Check this link:
> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > ibm.com%2Fsupport%2Fpages%2Fvvdsfix-unsupported-vsam-utility-used-corr
> > ect-problems-catalogs-and-vvds-entriesdata=05%7C01%7CSteely.Mark%
> > 40aaa-texas.com%7C0b4c39d54e974eae13b608da8b6d6e08%7Cd5f618ff295149048
> > f7e999c2dd97ab2%7C0%7C0%7C637975599375288953%7CUnknown%7CTWFpbGZsb3d8e
> > yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30
> > 00%7C%7C%7Csdata=AEcV2zpFaJDFTgdOx%2BgQzPAHNOcELTqSiDuxPtJJJLw%3D
> > reserved=0
> >
> > It talks about VVDS Fix utility - I am not sure if you can download it
> > any more - I have not been able to find a current download site.
> >
> > I have the load module. I might be able to add as an attachment and
> > send in an e-mail.
> >
> > Let me know.
> >
> > Thanks
> >
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Gibney, Dave
> > Sent: Wednesday, August 31, 2022 10:49 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: IDC3009I & IDC1566I with a weird dsn
> >
> > ATTENTION: This e-mail came from an external source. Do not open
> > attachments or click on links from unknown or unexpected emails.
> >
> >
> > Try a free trial of one of the Catalog utility addons.  Rocket has the
> > Mainstar product. Dinosoft has one.
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List  On
> > > Behalf Of Jack Zukt
> > > Sent: Wednesday, August 31, 2022 3:42 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: IDC3009I & IDC1566I with a weird dsn
> > >
> > > [EXTERNAL EMAIL]
> > >
> > > Hi Joe,
> > >
> > > Thank you for you input.  I had seen that.We are running 2.4 in
> > > which that APAR PTF  (UJ00743) has already been SUP (UJ02056) I have
> > > 34 pairs of those messages for 7 usercats, on a job that lists 66
> > > usercats. I think that if this was a bug t would affect all the
> listcats.
> > > I do not know how these entries got there. Probably some utility
> > > that did not end as expected. But as the "dataset name" does not
> > > adhere to MVS rules, I cannot find a way to get ride of them.
> > > Regards
> > > Jack
> > >
> > >
> > > On Tue, 30 Aug 2022 at 17:36, Joe Monk  wrote:
> > >
> > > > Might be this:
> > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fur
> > > ld
> > > efense.com%2Fv3%2F__https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fpages%2Fap
> > > ar
> > > %2FOdata=05%7C01%7CSteely.Mark%40aaa-texas.com%7Cc5a2914e21564f
> > > ae
> > > 855608da8b686bc7%7Cd5f618ff295149048f7e999c2dd97ab2%7C0%7C0%7C637975
> > > 57
> > > 7843502184%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> > > zI
> > > iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=EYxok8JRgE
> > > 3O
> > > 9XJEbwHA5VupkEsG19M51YqyqODNTWQ%3Dreserved=0
> > > A57619__;!!JmPEgBY0HMszNaDT!qbrh2jxLqNZygDoVJ62dAkhZOvSQxuhv78u
> > > bqh78z7GtnLWv1yIQyvd8gcrIKNPkHzKfBPotP9zFHQ$
> > > >
> > > > Users of CSI and LISTCAT Level may receive inconsistent errors on
> > > > entries that have no problem otherwise due to uninitialized
> > > > workarea data.
> > > >
> > > >
> > > > Joe
> > > >
> > > > On Tue, Aug 30, 2022 at 9:04 AM Jack Zukt  wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > Another situation that come up. Is anyone of you familiar with
> > > > > these
> > > > > messages:
> > > > >
> > > > > IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS
> > > IGG0CLFF-5
> > > > > IDC1566I ** .|. ...8..U...2. NOT
> > > > > LISTED
> > > > >
> > > > > As far as I can see, there is not one dataset with such a name
> > > > > on any of the available DASD. And yet I have 34 of those
> > > > > messages across 7 user catalogs (and they can be there for a
> > > > > long time) Aside from a RC(04) on the LISTCAT CAT(), there seems
> > > > > to be no other
> > > > issue.
> > > > > However, I cannot find a way to get rid of those as the dataset
> > > > > name
> > > 

Re: IDC3009I & IDC1566I with a weird dsn

[Jack Zukt]

Hi Dave,
I am afraid that you are right about that. It seems to be a catalog only
problem.
Regards
Jack

On Wed, 31 Aug 2022 at 17:31, Gibney, Dave <
03b5261cfd78-dmarc-requ...@listserv.ua.edu> wrote:

> I believe they are the best shot at fixing an issue like you describe.
> Since the garbage is in the usercat, FIXVVDS tools aren't likely helpful.
>
> You other possibility would be to define a new usercat and REPRO MERGECAT
> all the good entries to the new usercat.
>
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Jack Zukt
> > Sent: Wednesday, August 31, 2022 9:26 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: IDC3009I & IDC1566I with a weird dsn
> >
> > [EXTERNAL EMAIL]
> >
> > Hi Dave,
> > I do not think that I will get the go ahead for that, even it would be
> > worth a try.
> > Thank you anyway
> > Regards,
> > Jack
> >
> > On Wed, 31 Aug 2022 at 16:49, Gibney, Dave <
> > 03b5261cfd78-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > Try a free trial of one of the Catalog utility addons.  Rocket has the
> > > Mainstar product. Dinosoft has one.
> > >
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List 
> > On
> > > > Behalf Of Jack Zukt
> > > > Sent: Wednesday, August 31, 2022 3:42 AM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Re: IDC3009I & IDC1566I with a weird dsn
> > > >
> > > > [EXTERNAL EMAIL]
> > > >
> > > > Hi Joe,
> > > >
> > > > Thank you for you input.  I had seen that.We are running 2.4 in which
> > > that
> > > > APAR PTF  (UJ00743) has already been SUP (UJ02056)
> > > > I have 34 pairs of those messages for 7 usercats, on a job that
> lists 66
> > > > usercats. I think that if this was a bug t would affect all the
> listcats.
> > > > I do not know how these entries got there. Probably some utility
> that did
> > > > not end as expected. But as the "dataset name" does not adhere to MVS
> > > > rules, I cannot find a way to get ride of them.
> > > > Regards
> > > > Jack
> > > >
> > > >
> > > > On Tue, 30 Aug 2022 at 17:36, Joe Monk  wrote:
> > > >
> > > > > Might be this:
> > > >
> > https://urldefense.com/v3/__https://www.ibm.com/support/pages/apar/O
> > > >
> > A57619__;!!JmPEgBY0HMszNaDT!qbrh2jxLqNZygDoVJ62dAkhZOvSQxuhv78u
> > > > bqh78z7GtnLWv1yIQyvd8gcrIKNPkHzKfBPotP9zFHQ$
> > > > >
> > > > > Users of CSI and LISTCAT Level may receive inconsistent errors
> > > > > on entries that have no problem otherwise due to uninitialized
> > > > > workarea data.
> > > > >
> > > > >
> > > > > Joe
> > > > >
> > > > > On Tue, Aug 30, 2022 at 9:04 AM Jack Zukt 
> wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > Another situation that come up. Is anyone of you familiar with
> these
> > > > > > messages:
> > > > > >
> > > > > > IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS
> > > > IGG0CLFF-5
> > > > > > IDC1566I ** .|. ...8..U...2. NOT
> LISTED
> > > > > >
> > > > > > As far as I can see, there is not one dataset with such a name on
> > > any of
> > > > > > the available DASD. And yet I have 34 of those messages across 7
> user
> > > > > > catalogs (and they can be there for a long time)
> > > > > > Aside from a RC(04) on the LISTCAT CAT(), there seems to be no
> other
> > > > > issue.
> > > > > > However, I cannot find a way to get rid of those as the dataset
> name
> > > > does
> > > > > > not adhere to restrictions.
> > > > > > Any ideas?
> > > > > > 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
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: 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: IDC3009I & IDC1566I with a weird dsn

[Carmen Vitullo]

ok, just checking, as other have suggested, if you have Dynosoft's Trex 
or another comparable product, I think these can fix your issues.


if they are FDR dummy 'CKPT' files, I'd just rerun the compactor job on 
these volumes


Carmen

On 8/31/2022 11:22 AM, Jack Zukt wrote:

Hi Carmen
Thanks for the idea
Unfortunately it gives the same result
Regards
Jack

On Wed, 31 Aug 2022 at 16:34, Carmen Vitullo  wrote:


just checking back, Jack, you said you tried IDCAMS delete, If I had no
luck using DELETE  VVR, I sometimes have luck with using NVR, the
component types are different

Carmen

On 8/31/2022 8:04 AM, Jack Zukt wrote:

Hi Carmen
Thank you for the input. I have tried IDCAMS DELETE but to no avail.
As for FDR, you are probably right. It might be something left from a job
running FDR that ended abnormally. But considering the number of "lost"
entries, some of those jobs must have considered complete even with the
errors.
Regards,
Jack

On Wed, 31 Aug 2022 at 13:58, Carmen Vitullo 

wrote:

Jack, 2 things some to mind,  have you tried to use IDCAMS to delete the
entry using NVR (non vsam) file

DELETE FILE(DD1) -

  'COMPONENT' NVR

also I recall, you use FDR to compact volumes, and one volume during
compaction fails it leaves a 'pointer' for the lack of a better term as
an non standard data set name that cannot be deleted by normal methods,
to get rid of the file you need to run the compact job again to a
successful end


Carmen

On 8/31/2022 5:50 AM, Jack Zukt wrote:

Hi Allan,
This "thing" has got no description; it is not a NONVSAM nor a VSAM

entry.

There is no VOLSER associared with it. I tried using IDCAMS DELETE

NONVSAM

but all I got in return was
IDC3203I ITEM '.|.' DOES NOT ADHERE TO RESTRICTIONS. Which is not
surprising considering that it does have spaces in it.

Regards
Jack


On Tue, 30 Aug 2022 at 21:28, Allan Staller <
0387911dea17-dmarc-requ...@listserv.ua.edu> wrote:


Classification: Confidential

LISTCAT ENT(entryname) ALL
Select the component (cluster index) and volume (xx)

Use IDCAMS in batch:
//STEP EXEC IDCAMS
//SYSPRINT  DD *
//DD1   DD UNIT=SYSDA,DISP=SHR,VOL=SER=xx
//SYSIN DD  *
DEL componentname VVR FILE(DD1)
/*

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On

Behalf

Of Jack Zukt
Sent: Tuesday, August 30, 2022 9:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IDC3009I & IDC1566I with a weird dsn

[CAUTION: This Email is from outside the Organization. Unless you

trust

the sender, Don’t click links or open attachments as it may be a

Phishing

email, which can steal your Information and compromise your Computer.]

Hi all,

Another situation that come up. Is anyone of you familiar with these
messages:

IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS IGG0CLFF-5
IDC1566I ** .|. ...8..U...2. NOT LISTED

As far as I can see, there is not one dataset with such a name on any

of

the available DASD. And yet I have 34 of those messages across 7 user
catalogs (and they can be there for a long time) Aside from a RC(04)

on

the

LISTCAT CAT(), there seems to be no other issue.
However, I cannot find a way to get rid of those as the dataset name

does

not adhere to restrictions.
Any ideas?
jack

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

email

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

The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only. E-mail transmission is not
guaranteed to be secure or error-free as information could be

intercepted,

corrupted, lost, destroyed, arrive late or incomplete, or may contain
viruses in transmission. The e mail and its contents (with or without
referred errors) shall therefore not attach any liability on the

originator

or HCL or its affiliates. Views or opinions, if any, presented in this
email are solely those of the author and may not necessarily reflect

the

views or opinions of HCL or its affiliates. Any form of reproduction,
dissemination, copying, disclosure, modification, distribution and /

or

publication of this message without the prior written consent of

authorized

representative of HCL is strictly prohibited. If you have received

this

email in error please delete it and notify the sender immediately.

Before

opening any email and/or attachments, please check them for viruses

and

other defects.


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

IBM-MAIN

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

Re: Calculate deltas using DFSORT

[Sri h Kolusu]

Hi,

One email with multiple responses.

>>. I can never understand what the DFSORT solutions are doing from reading the 
>>control cards, and I'm sure I am not alone there. A programming language 
>>makes it much easier for the person who has to understand it in the future.

Andrew,

Just to be clear, DFSORT is an Utility which does a lot of stuff and is not a 
match for a programming language. As for the understanding the control cards, 
it all depends on how you perceive them.  If you put a little effort like you 
do when you learn a new programming language, then it is a walk in the park.


>>I can post a note here describing what I'm trying to do along with some data 
>>samples, and like the elves who make shoes, complete JCL and SYSIN will 
>>magically appear the next morning.

Tom,

I believe this platform is to share and help each other. I for one believe in 
sharing the knowledge and in the process, I might learn a thing or two from 
other topics. It also helps us to understand the customer requirements and 
implement them in future.There may be few bad apples who might take advantage 
of the help being received here, but that shouldn't stop us from sharing the 
knowledge.

>>Although this is a joke... some respect for Sri please.

KB,

Thanks. Much appreciated for your support.

>>The rest is reality as I see it.  Whether that's good or bad I guess depends 
>>on your point of view.

The people who take advantage of the help they receive here will only thrive 
for a short period of time.

>>Kolusu's assistance is priceless!

Paul,

Thanks.

>>The last sentence beginning "Thus ..." is incorrect.

Thanks for bringing it to our attention. we will try to clarify it.

>>The DFSORT manual (and others) should not attempt to explain regular 
>>expressions.  They should defer to citing a single publication with such an 
>>explanation.

I completely agree, however each component within IBM is implementing a regular 
expression flavor. Different regular expression flavors are not fully 
compatible with each other. So it is difficult to have 1 central publication.


>>(I forgot to ask whether the LOCALE command affects the interpretation of 
>>metacharacters in SYSIN.  And to note that the Guide's using a 
>>proportional-spaced font makes syntax runes and examples confusing.)


Paul,

Locale is NOT supported with regular expressions and it is documented here

https://www.ibm.com/docs/en/zos/2.5.0?topic=expressions-regular-application-notes


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

Re: IDC3009I & IDC1566I with a weird dsn

[Steely.Mark]

This is what I used for the SYSIN:

//SYSINDD  *   
CMD=DELBCSR;XXX.DSNCPY.X  ;  
/* 
// 
//* NOTE: DSN MUST BE 44 CHARACTERS PADDED WITH BLANKS 

For some reason it took me a long time to figure out the DSN format for the 
DELBCSR command. 

Warning:  Use at you own risk 

Thanks

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jack Zukt
Sent: Wednesday, August 31, 2022 11:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IDC3009I & IDC1566I with a weird dsn

ATTENTION: This e-mail came from an external source. Do not open attachments or 
click on links from unknown or unexpected emails.


Hi Mark,

Thank you for the suggestion.
There is FIXVVDS on SYS1.LINKLIB with a description on SYS1.SAMPLIB. I am going 
to read and maybe give it a try.
Regards
Jack

On Wed, 31 Aug 2022 at 17:01, Steely.Mark  wrote:

> Check this link:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ibm.com%2Fsupport%2Fpages%2Fvvdsfix-unsupported-vsam-utility-used-corr
> ect-problems-catalogs-and-vvds-entriesdata=05%7C01%7CSteely.Mark%
> 40aaa-texas.com%7C0b4c39d54e974eae13b608da8b6d6e08%7Cd5f618ff295149048
> f7e999c2dd97ab2%7C0%7C0%7C637975599375288953%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30
> 00%7C%7C%7Csdata=AEcV2zpFaJDFTgdOx%2BgQzPAHNOcELTqSiDuxPtJJJLw%3D
> reserved=0
>
> It talks about VVDS Fix utility - I am not sure if you can download it 
> any more - I have not been able to find a current download site.
>
> I have the load module. I might be able to add as an attachment and 
> send in an e-mail.
>
> Let me know.
>
> Thanks
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Gibney, Dave
> Sent: Wednesday, August 31, 2022 10:49 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IDC3009I & IDC1566I with a weird dsn
>
> ATTENTION: This e-mail came from an external source. Do not open 
> attachments or click on links from unknown or unexpected emails.
>
>
> Try a free trial of one of the Catalog utility addons.  Rocket has the 
> Mainstar product. Dinosoft has one.
>
> > -Original Message-
> > From: IBM Mainframe Discussion List  On 
> > Behalf Of Jack Zukt
> > Sent: Wednesday, August 31, 2022 3:42 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: IDC3009I & IDC1566I with a weird dsn
> >
> > [EXTERNAL EMAIL]
> >
> > Hi Joe,
> >
> > Thank you for you input.  I had seen that.We are running 2.4 in 
> > which that APAR PTF  (UJ00743) has already been SUP (UJ02056) I have 
> > 34 pairs of those messages for 7 usercats, on a job that lists 66 
> > usercats. I think that if this was a bug t would affect all the listcats.
> > I do not know how these entries got there. Probably some utility 
> > that did not end as expected. But as the "dataset name" does not 
> > adhere to MVS rules, I cannot find a way to get ride of them.
> > Regards
> > Jack
> >
> >
> > On Tue, 30 Aug 2022 at 17:36, Joe Monk  wrote:
> >
> > > Might be this:
> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fur
> > ld 
> > efense.com%2Fv3%2F__https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fpages%2Fap
> > ar 
> > %2FOdata=05%7C01%7CSteely.Mark%40aaa-texas.com%7Cc5a2914e21564f
> > ae
> > 855608da8b686bc7%7Cd5f618ff295149048f7e999c2dd97ab2%7C0%7C0%7C637975
> > 57 
> > 7843502184%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> > zI 
> > iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=EYxok8JRgE
> > 3O
> > 9XJEbwHA5VupkEsG19M51YqyqODNTWQ%3Dreserved=0
> > A57619__;!!JmPEgBY0HMszNaDT!qbrh2jxLqNZygDoVJ62dAkhZOvSQxuhv78u
> > bqh78z7GtnLWv1yIQyvd8gcrIKNPkHzKfBPotP9zFHQ$
> > >
> > > Users of CSI and LISTCAT Level may receive inconsistent errors on 
> > > entries that have no problem otherwise due to uninitialized 
> > > workarea data.
> > >
> > >
> > > Joe
> > >
> > > On Tue, Aug 30, 2022 at 9:04 AM Jack Zukt  wrote:
> > >
> > > > Hi all,
> > > >
> > > > Another situation that come up. Is anyone of you familiar with 
> > > > these
> > > > messages:
> > > >
> > > > IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS
> > IGG0CLFF-5
> > > > IDC1566I ** .|. ...8..U...2. NOT 
> > > > LISTED
> > > >
> > > > As far as I can see, there is not one dataset with such a name 
> > > > on any of the available DASD. And yet I have 34 of those 
> > > > messages across 7 user catalogs (and they can be there for a 
> > > > long time) Aside from a RC(04) on the LISTCAT CAT(), there seems 
> > > > to be no other
> > > issue.
> > > > However, I cannot find a way to get rid of those as the dataset 
> > > > name
> > does
> > > > not adhere to restrictions.
> > > > Any ideas?
> > > > jack
> > > >
> > > > 
> > > > --
> > > >  For IBM-MAIN 

Re: IDC3009I & IDC1566I with a weird dsn

[Gibney, Dave]

I believe they are the best shot at fixing an issue like you describe. 
Since the garbage is in the usercat, FIXVVDS tools aren't likely helpful.

You other possibility would be to define a new usercat and REPRO MERGECAT all 
the good entries to the new usercat.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Jack Zukt
> Sent: Wednesday, August 31, 2022 9:26 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IDC3009I & IDC1566I with a weird dsn
> 
> [EXTERNAL EMAIL]
> 
> Hi Dave,
> I do not think that I will get the go ahead for that, even it would be
> worth a try.
> Thank you anyway
> Regards,
> Jack
> 
> On Wed, 31 Aug 2022 at 16:49, Gibney, Dave <
> 03b5261cfd78-dmarc-requ...@listserv.ua.edu> wrote:
> 
> > Try a free trial of one of the Catalog utility addons.  Rocket has the
> > Mainstar product. Dinosoft has one.
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List 
> On
> > > Behalf Of Jack Zukt
> > > Sent: Wednesday, August 31, 2022 3:42 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: IDC3009I & IDC1566I with a weird dsn
> > >
> > > [EXTERNAL EMAIL]
> > >
> > > Hi Joe,
> > >
> > > Thank you for you input.  I had seen that.We are running 2.4 in which
> > that
> > > APAR PTF  (UJ00743) has already been SUP (UJ02056)
> > > I have 34 pairs of those messages for 7 usercats, on a job that lists 66
> > > usercats. I think that if this was a bug t would affect all the listcats.
> > > I do not know how these entries got there. Probably some utility that did
> > > not end as expected. But as the "dataset name" does not adhere to MVS
> > > rules, I cannot find a way to get ride of them.
> > > Regards
> > > Jack
> > >
> > >
> > > On Tue, 30 Aug 2022 at 17:36, Joe Monk  wrote:
> > >
> > > > Might be this:
> > >
> https://urldefense.com/v3/__https://www.ibm.com/support/pages/apar/O
> > >
> A57619__;!!JmPEgBY0HMszNaDT!qbrh2jxLqNZygDoVJ62dAkhZOvSQxuhv78u
> > > bqh78z7GtnLWv1yIQyvd8gcrIKNPkHzKfBPotP9zFHQ$
> > > >
> > > > Users of CSI and LISTCAT Level may receive inconsistent errors
> > > > on entries that have no problem otherwise due to uninitialized
> > > > workarea data.
> > > >
> > > >
> > > > Joe
> > > >
> > > > On Tue, Aug 30, 2022 at 9:04 AM Jack Zukt  wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > Another situation that come up. Is anyone of you familiar with these
> > > > > messages:
> > > > >
> > > > > IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS
> > > IGG0CLFF-5
> > > > > IDC1566I ** .|. ...8..U...2. NOT LISTED
> > > > >
> > > > > As far as I can see, there is not one dataset with such a name on
> > any of
> > > > > the available DASD. And yet I have 34 of those messages across 7 user
> > > > > catalogs (and they can be there for a long time)
> > > > > Aside from a RC(04) on the LISTCAT CAT(), there seems to be no other
> > > > issue.
> > > > > However, I cannot find a way to get rid of those as the dataset name
> > > does
> > > > > not adhere to restrictions.
> > > > > Any ideas?
> > > > > 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
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: 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: IDC3009I & IDC1566I with a weird dsn

[Jack Zukt]

Hi Dave,
I do not think that I will get the go ahead for that, even it would be
worth a try.
Thank you anyway
Regards,
Jack

On Wed, 31 Aug 2022 at 16:49, Gibney, Dave <
03b5261cfd78-dmarc-requ...@listserv.ua.edu> wrote:

> Try a free trial of one of the Catalog utility addons.  Rocket has the
> Mainstar product. Dinosoft has one.
>
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Jack Zukt
> > Sent: Wednesday, August 31, 2022 3:42 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: IDC3009I & IDC1566I with a weird dsn
> >
> > [EXTERNAL EMAIL]
> >
> > Hi Joe,
> >
> > Thank you for you input.  I had seen that.We are running 2.4 in which
> that
> > APAR PTF  (UJ00743) has already been SUP (UJ02056)
> > I have 34 pairs of those messages for 7 usercats, on a job that lists 66
> > usercats. I think that if this was a bug t would affect all the listcats.
> > I do not know how these entries got there. Probably some utility that did
> > not end as expected. But as the "dataset name" does not adhere to MVS
> > rules, I cannot find a way to get ride of them.
> > Regards
> > Jack
> >
> >
> > On Tue, 30 Aug 2022 at 17:36, Joe Monk  wrote:
> >
> > > Might be this:
> > https://urldefense.com/v3/__https://www.ibm.com/support/pages/apar/O
> > A57619__;!!JmPEgBY0HMszNaDT!qbrh2jxLqNZygDoVJ62dAkhZOvSQxuhv78u
> > bqh78z7GtnLWv1yIQyvd8gcrIKNPkHzKfBPotP9zFHQ$
> > >
> > > Users of CSI and LISTCAT Level may receive inconsistent errors
> > > on entries that have no problem otherwise due to uninitialized
> > > workarea data.
> > >
> > >
> > > Joe
> > >
> > > On Tue, Aug 30, 2022 at 9:04 AM Jack Zukt  wrote:
> > >
> > > > Hi all,
> > > >
> > > > Another situation that come up. Is anyone of you familiar with these
> > > > messages:
> > > >
> > > > IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS
> > IGG0CLFF-5
> > > > IDC1566I ** .|. ...8..U...2. NOT LISTED
> > > >
> > > > As far as I can see, there is not one dataset with such a name on
> any of
> > > > the available DASD. And yet I have 34 of those messages across 7 user
> > > > catalogs (and they can be there for a long time)
> > > > Aside from a RC(04) on the LISTCAT CAT(), there seems to be no other
> > > issue.
> > > > However, I cannot find a way to get rid of those as the dataset name
> > does
> > > > not adhere to restrictions.
> > > > Any ideas?
> > > > 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
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: 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: IDC3009I & IDC1566I with a weird dsn

[Jack Zukt]

Hi Mark,

Thank you for the suggestion.
There is FIXVVDS on SYS1.LINKLIB with a description on SYS1.SAMPLIB. I am
going to read and maybe give it a try.
Regards
Jack

On Wed, 31 Aug 2022 at 17:01, Steely.Mark  wrote:

> Check this link:
> https://www.ibm.com/support/pages/vvdsfix-unsupported-vsam-utility-used-correct-problems-catalogs-and-vvds-entries
>
> It talks about VVDS Fix utility - I am not sure if you can download it any
> more - I have not been able to find a current download site.
>
> I have the load module. I might be able to add as an attachment and send
> in an e-mail.
>
> Let me know.
>
> Thanks
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Gibney, Dave
> Sent: Wednesday, August 31, 2022 10:49 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IDC3009I & IDC1566I with a weird dsn
>
> ATTENTION: This e-mail came from an external source. Do not open
> attachments or click on links from unknown or unexpected emails.
>
>
> Try a free trial of one of the Catalog utility addons.  Rocket has the
> Mainstar product. Dinosoft has one.
>
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Jack Zukt
> > Sent: Wednesday, August 31, 2022 3:42 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: IDC3009I & IDC1566I with a weird dsn
> >
> > [EXTERNAL EMAIL]
> >
> > Hi Joe,
> >
> > Thank you for you input.  I had seen that.We are running 2.4 in which
> > that APAR PTF  (UJ00743) has already been SUP (UJ02056) I have 34
> > pairs of those messages for 7 usercats, on a job that lists 66
> > usercats. I think that if this was a bug t would affect all the listcats.
> > I do not know how these entries got there. Probably some utility that
> > did not end as expected. But as the "dataset name" does not adhere to
> > MVS rules, I cannot find a way to get ride of them.
> > Regards
> > Jack
> >
> >
> > On Tue, 30 Aug 2022 at 17:36, Joe Monk  wrote:
> >
> > > Might be this:
> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> > efense.com%2Fv3%2F__https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fpages%2Fapar
> > %2FOdata=05%7C01%7CSteely.Mark%40aaa-texas.com%7Cc5a2914e21564fae
> > 855608da8b686bc7%7Cd5f618ff295149048f7e999c2dd97ab2%7C0%7C0%7C63797557
> > 7843502184%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> > iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=EYxok8JRgE3O
> > 9XJEbwHA5VupkEsG19M51YqyqODNTWQ%3Dreserved=0
> > A57619__;!!JmPEgBY0HMszNaDT!qbrh2jxLqNZygDoVJ62dAkhZOvSQxuhv78u
> > bqh78z7GtnLWv1yIQyvd8gcrIKNPkHzKfBPotP9zFHQ$
> > >
> > > Users of CSI and LISTCAT Level may receive inconsistent errors on
> > > entries that have no problem otherwise due to uninitialized workarea
> > > data.
> > >
> > >
> > > Joe
> > >
> > > On Tue, Aug 30, 2022 at 9:04 AM Jack Zukt  wrote:
> > >
> > > > Hi all,
> > > >
> > > > Another situation that come up. Is anyone of you familiar with
> > > > these
> > > > messages:
> > > >
> > > > IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS
> > IGG0CLFF-5
> > > > IDC1566I ** .|. ...8..U...2. NOT
> > > > LISTED
> > > >
> > > > As far as I can see, there is not one dataset with such a name on
> > > > any of the available DASD. And yet I have 34 of those messages
> > > > across 7 user catalogs (and they can be there for a long time)
> > > > Aside from a RC(04) on the LISTCAT CAT(), there seems to be no
> > > > other
> > > issue.
> > > > However, I cannot find a way to get rid of those as the dataset
> > > > name
> > does
> > > > not adhere to restrictions.
> > > > Any ideas?
> > > > 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
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: 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: IDC3009I & IDC1566I with a weird dsn

[Jack Zukt]

Hi Carmen
Thanks for the idea
Unfortunately it gives the same result
Regards
Jack

On Wed, 31 Aug 2022 at 16:34, Carmen Vitullo  wrote:

> just checking back, Jack, you said you tried IDCAMS delete, If I had no
> luck using DELETE  VVR, I sometimes have luck with using NVR, the
> component types are different
>
> Carmen
>
> On 8/31/2022 8:04 AM, Jack Zukt wrote:
> > Hi Carmen
> > Thank you for the input. I have tried IDCAMS DELETE but to no avail.
> > As for FDR, you are probably right. It might be something left from a job
> > running FDR that ended abnormally. But considering the number of "lost"
> > entries, some of those jobs must have considered complete even with the
> > errors.
> > Regards,
> > Jack
> >
> > On Wed, 31 Aug 2022 at 13:58, Carmen Vitullo 
> wrote:
> >
> >> Jack, 2 things some to mind,  have you tried to use IDCAMS to delete the
> >> entry using NVR (non vsam) file
> >>
> >> DELETE FILE(DD1) -
> >>
> >>  'COMPONENT' NVR
> >>
> >> also I recall, you use FDR to compact volumes, and one volume during
> >> compaction fails it leaves a 'pointer' for the lack of a better term as
> >> an non standard data set name that cannot be deleted by normal methods,
> >> to get rid of the file you need to run the compact job again to a
> >> successful end
> >>
> >>
> >> Carmen
> >>
> >> On 8/31/2022 5:50 AM, Jack Zukt wrote:
> >>> Hi Allan,
> >>> This "thing" has got no description; it is not a NONVSAM nor a VSAM
> >> entry.
> >>> There is no VOLSER associared with it. I tried using IDCAMS DELETE
> >> NONVSAM
> >>> but all I got in return was
> >>> IDC3203I ITEM '.|.' DOES NOT ADHERE TO RESTRICTIONS. Which is not
> >>> surprising considering that it does have spaces in it.
> >>>
> >>> Regards
> >>> Jack
> >>>
> >>>
> >>> On Tue, 30 Aug 2022 at 21:28, Allan Staller <
> >>> 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote:
> >>>
>  Classification: Confidential
> 
>  LISTCAT ENT(entryname) ALL
>  Select the component (cluster index) and volume (xx)
> 
>  Use IDCAMS in batch:
>  //STEP EXEC IDCAMS
>  //SYSPRINT  DD *
>  //DD1   DD UNIT=SYSDA,DISP=SHR,VOL=SER=xx
>  //SYSIN DD  *
> DEL componentname VVR FILE(DD1)
>  /*
> 
>  HTH,
> 
>  -Original Message-
>  From: IBM Mainframe Discussion List  On
> >> Behalf
>  Of Jack Zukt
>  Sent: Tuesday, August 30, 2022 9:04 AM
>  To: IBM-MAIN@LISTSERV.UA.EDU
>  Subject: IDC3009I & IDC1566I with a weird dsn
> 
>  [CAUTION: This Email is from outside the Organization. Unless you
> trust
>  the sender, Don’t click links or open attachments as it may be a
> >> Phishing
>  email, which can steal your Information and compromise your Computer.]
> 
>  Hi all,
> 
>  Another situation that come up. Is anyone of you familiar with these
>  messages:
> 
>  IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS IGG0CLFF-5
>  IDC1566I ** .|. ...8..U...2. NOT LISTED
> 
>  As far as I can see, there is not one dataset with such a name on any
> of
>  the available DASD. And yet I have 34 of those messages across 7 user
>  catalogs (and they can be there for a long time) Aside from a RC(04)
> on
> >> the
>  LISTCAT CAT(), there seems to be no other issue.
>  However, I cannot find a way to get rid of those as the dataset name
> >> does
>  not adhere to restrictions.
>  Any ideas?
>  jack
> 
>  --
>  For IBM-MAIN subscribe / signoff / archive access instructions, send
> >> email
>  to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>  ::DISCLAIMER::
>  
>  The contents of this e-mail and any attachment(s) are confidential and
>  intended for the named recipient(s) only. E-mail transmission is not
>  guaranteed to be secure or error-free as information could be
> >> intercepted,
>  corrupted, lost, destroyed, arrive late or incomplete, or may contain
>  viruses in transmission. The e mail and its contents (with or without
>  referred errors) shall therefore not attach any liability on the
> >> originator
>  or HCL or its affiliates. Views or opinions, if any, presented in this
>  email are solely those of the author and may not necessarily reflect
> the
>  views or opinions of HCL or its affiliates. Any form of reproduction,
>  dissemination, copying, disclosure, modification, distribution and /
> or
>  publication of this message without the prior written consent of
> >> authorized
>  representative of HCL is strictly prohibited. If you have received
> this
>  email in error please delete it and notify the sender immediately.
> >> Before
>  opening any email and/or attachments, please check them for viruses
> and
>  other defects.
>  

Re: Calculate deltas using DFSORT

[Paul Gilmartin]

(I forgot to ask whether the LOCALE command affects the interpretation
of metacharacters in SYSIN.  And to note that the Guide's using a
proportional-spaced font makes syntax runes and examples confusing.)

On Wed, 31 Aug 2022 10:21:42 -0500, Walt Farrell wrote:

>On Wed, 31 Aug 2022 10:03:21 -0500, Paul Gilmartin  wrote:
>
>>
>>"[^abc]" matches any string containing a character
>>other than a, b, or c.  It matches "wombat".  However,
>>"^[^abc]*$" matches strings containing no character
>>other than a, b, or c.   It does not match "wombat".
>
>Was that something you said, or something you're quoting from the manual? I'm 
>not sure.
>
That;s what I said.  The passage in z⧸OS DFSORT Application Programming Guide
which I quoted and you trimmed was:

Also, in a table:
The caret symbol, when inside square brackets,
negates the characters within the square brackets.
Thus [^abc], if compared to other strings, would fail
to match any that contains even one a, b, or c.

Further on:
The following patterns are given as examples, along with descriptions of 
what they match:

abc Matches any record containing the three letters abc in that order.
Correct.  "containing" because it's unanchored.

a.c Matches any string beginning with the letter a, followed by any 
character, followed by the letter c.
Incorrect.  It's unanchored.  "beginning with" should be "containing".

(But is there a nice distinction between "record containing" and
"string beginning with"  of which I'm unaware.  Are those terms defined
and distinguished?)

>In any case, "[^abc]" does not match "wombat". It matches only a single 
>character of a string. So, it might match the "w" in "wombat", or the "o", or 
>the "m", or the "t", depending on other details of the input string being 
>processed, and the application doing the processing.
> 
Absent an anchor ("^" and/or "$") a pattern can be matched anywhere in a 
subject.

>I agree with your comment (which I omitted from my quote) that the DFSORT 
>books should not try to explain reg-ex processing, unless they have written 
>their own processor instead of reusing someone else's.
>
+1
But it might be proper to emphasize any difference between DFSORT's use of
reg-ex and traditional beliefs.

-- 
Thanks,
gil

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

Re: IDC3009I & IDC1566I with a weird dsn

[Steely.Mark]

Check this link: 
https://www.ibm.com/support/pages/vvdsfix-unsupported-vsam-utility-used-correct-problems-catalogs-and-vvds-entries

It talks about VVDS Fix utility - I am not sure if you can download it any more 
- I have not been able to find a current download site. 

I have the load module. I might be able to add as an attachment and send in an 
e-mail. 

Let me know.  

Thanks



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gibney, Dave
Sent: Wednesday, August 31, 2022 10:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IDC3009I & IDC1566I with a weird dsn

ATTENTION: This e-mail came from an external source. Do not open attachments or 
click on links from unknown or unexpected emails.


Try a free trial of one of the Catalog utility addons.  Rocket has the Mainstar 
product. Dinosoft has one.

> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Jack Zukt
> Sent: Wednesday, August 31, 2022 3:42 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IDC3009I & IDC1566I with a weird dsn
>
> [EXTERNAL EMAIL]
>
> Hi Joe,
>
> Thank you for you input.  I had seen that.We are running 2.4 in which 
> that APAR PTF  (UJ00743) has already been SUP (UJ02056) I have 34 
> pairs of those messages for 7 usercats, on a job that lists 66 
> usercats. I think that if this was a bug t would affect all the listcats.
> I do not know how these entries got there. Probably some utility that 
> did not end as expected. But as the "dataset name" does not adhere to 
> MVS rules, I cannot find a way to get ride of them.
> Regards
> Jack
>
>
> On Tue, 30 Aug 2022 at 17:36, Joe Monk  wrote:
>
> > Might be this:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fpages%2Fapar
> %2FOdata=05%7C01%7CSteely.Mark%40aaa-texas.com%7Cc5a2914e21564fae
> 855608da8b686bc7%7Cd5f618ff295149048f7e999c2dd97ab2%7C0%7C0%7C63797557
> 7843502184%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=EYxok8JRgE3O
> 9XJEbwHA5VupkEsG19M51YqyqODNTWQ%3Dreserved=0
> A57619__;!!JmPEgBY0HMszNaDT!qbrh2jxLqNZygDoVJ62dAkhZOvSQxuhv78u
> bqh78z7GtnLWv1yIQyvd8gcrIKNPkHzKfBPotP9zFHQ$
> >
> > Users of CSI and LISTCAT Level may receive inconsistent errors on 
> > entries that have no problem otherwise due to uninitialized workarea 
> > data.
> >
> >
> > Joe
> >
> > On Tue, Aug 30, 2022 at 9:04 AM Jack Zukt  wrote:
> >
> > > Hi all,
> > >
> > > Another situation that come up. Is anyone of you familiar with 
> > > these
> > > messages:
> > >
> > > IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS
> IGG0CLFF-5
> > > IDC1566I ** .|. ...8..U...2. NOT 
> > > LISTED
> > >
> > > As far as I can see, there is not one dataset with such a name on 
> > > any of the available DASD. And yet I have 34 of those messages 
> > > across 7 user catalogs (and they can be there for a long time) 
> > > Aside from a RC(04) on the LISTCAT CAT(), there seems to be no 
> > > other
> > issue.
> > > However, I cannot find a way to get rid of those as the dataset 
> > > name
> does
> > > not adhere to restrictions.
> > > Any ideas?
> > > 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

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: 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: IDC3009I & IDC1566I with a weird dsn

[Gibney, Dave]

Try a free trial of one of the Catalog utility addons.  Rocket has the Mainstar 
product. Dinosoft has one.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Jack Zukt
> Sent: Wednesday, August 31, 2022 3:42 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IDC3009I & IDC1566I with a weird dsn
> 
> [EXTERNAL EMAIL]
> 
> Hi Joe,
> 
> Thank you for you input.  I had seen that.We are running 2.4 in which that
> APAR PTF  (UJ00743) has already been SUP (UJ02056)
> I have 34 pairs of those messages for 7 usercats, on a job that lists 66
> usercats. I think that if this was a bug t would affect all the listcats.
> I do not know how these entries got there. Probably some utility that did
> not end as expected. But as the "dataset name" does not adhere to MVS
> rules, I cannot find a way to get ride of them.
> Regards
> Jack
> 
> 
> On Tue, 30 Aug 2022 at 17:36, Joe Monk  wrote:
> 
> > Might be this:
> https://urldefense.com/v3/__https://www.ibm.com/support/pages/apar/O
> A57619__;!!JmPEgBY0HMszNaDT!qbrh2jxLqNZygDoVJ62dAkhZOvSQxuhv78u
> bqh78z7GtnLWv1yIQyvd8gcrIKNPkHzKfBPotP9zFHQ$
> >
> > Users of CSI and LISTCAT Level may receive inconsistent errors
> > on entries that have no problem otherwise due to uninitialized
> > workarea data.
> >
> >
> > Joe
> >
> > On Tue, Aug 30, 2022 at 9:04 AM Jack Zukt  wrote:
> >
> > > Hi all,
> > >
> > > Another situation that come up. Is anyone of you familiar with these
> > > messages:
> > >
> > > IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS
> IGG0CLFF-5
> > > IDC1566I ** .|. ...8..U...2. NOT LISTED
> > >
> > > As far as I can see, there is not one dataset with such a name on any of
> > > the available DASD. And yet I have 34 of those messages across 7 user
> > > catalogs (and they can be there for a long time)
> > > Aside from a RC(04) on the LISTCAT CAT(), there seems to be no other
> > issue.
> > > However, I cannot find a way to get rid of those as the dataset name
> does
> > > not adhere to restrictions.
> > > Any ideas?
> > > 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

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

Re: IDC3009I & IDC1566I with a weird dsn

[Carmen Vitullo]

just checking back, Jack, you said you tried IDCAMS delete, If I had no 
luck using DELETE  VVR, I sometimes have luck with using NVR, the 
component types are different


Carmen

On 8/31/2022 8:04 AM, Jack Zukt wrote:

Hi Carmen
Thank you for the input. I have tried IDCAMS DELETE but to no avail.
As for FDR, you are probably right. It might be something left from a job
running FDR that ended abnormally. But considering the number of "lost"
entries, some of those jobs must have considered complete even with the
errors.
Regards,
Jack

On Wed, 31 Aug 2022 at 13:58, Carmen Vitullo  wrote:


Jack, 2 things some to mind,  have you tried to use IDCAMS to delete the
entry using NVR (non vsam) file

DELETE FILE(DD1) -

 'COMPONENT' NVR

also I recall, you use FDR to compact volumes, and one volume during
compaction fails it leaves a 'pointer' for the lack of a better term as
an non standard data set name that cannot be deleted by normal methods,
to get rid of the file you need to run the compact job again to a
successful end


Carmen

On 8/31/2022 5:50 AM, Jack Zukt wrote:

Hi Allan,
This "thing" has got no description; it is not a NONVSAM nor a VSAM

entry.

There is no VOLSER associared with it. I tried using IDCAMS DELETE

NONVSAM

but all I got in return was
IDC3203I ITEM '.|.' DOES NOT ADHERE TO RESTRICTIONS. Which is not
surprising considering that it does have spaces in it.

Regards
Jack


On Tue, 30 Aug 2022 at 21:28, Allan Staller <
0387911dea17-dmarc-requ...@listserv.ua.edu> wrote:


Classification: Confidential

LISTCAT ENT(entryname) ALL
Select the component (cluster index) and volume (xx)

Use IDCAMS in batch:
//STEP EXEC IDCAMS
//SYSPRINT  DD *
//DD1   DD UNIT=SYSDA,DISP=SHR,VOL=SER=xx
//SYSIN DD  *
   DEL componentname VVR FILE(DD1)
/*

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On

Behalf

Of Jack Zukt
Sent: Tuesday, August 30, 2022 9:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IDC3009I & IDC1566I with a weird dsn

[CAUTION: This Email is from outside the Organization. Unless you trust
the sender, Don’t click links or open attachments as it may be a

Phishing

email, which can steal your Information and compromise your Computer.]

Hi all,

Another situation that come up. Is anyone of you familiar with these
messages:

IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS IGG0CLFF-5
IDC1566I ** .|. ...8..U...2. NOT LISTED

As far as I can see, there is not one dataset with such a name on any of
the available DASD. And yet I have 34 of those messages across 7 user
catalogs (and they can be there for a long time) Aside from a RC(04) on

the

LISTCAT CAT(), there seems to be no other issue.
However, I cannot find a way to get rid of those as the dataset name

does

not adhere to restrictions.
Any ideas?
jack

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

email

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

The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only. E-mail transmission is not
guaranteed to be secure or error-free as information could be

intercepted,

corrupted, lost, destroyed, arrive late or incomplete, or may contain
viruses in transmission. The e mail and its contents (with or without
referred errors) shall therefore not attach any liability on the

originator

or HCL or its affiliates. Views or opinions, if any, presented in this
email are solely those of the author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction,
dissemination, copying, disclosure, modification, distribution and / or
publication of this message without the prior written consent of

authorized

representative of HCL is strictly prohibited. If you have received this
email in error please delete it and notify the sender immediately.

Before

opening any email and/or attachments, please check them for viruses and
other defects.


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


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

Re: Connect CDC SQDATA VSAM

[Richard Philyaw]

Hi KB,

We support access to any sequential file.  I’m not an IMS expert, and someone 
can correct me, but IMS logs appear to be allocated as a set of sequential 
files.

As for OPERLOG/SYSLOG, assuming you mean DASD log data sets, yes that should 
work.

Also, to clarify my comments about NFS versions: as of Windows 10/11 and most 
current Windows Server I believe the correct version is NFS V3, but the 
concerns about security and performance vs NFS V4 still exist at V3.  We are 
including an installable NFS V4.x driver for Windows in our latest build.

I hope this helps.

Thanks,
Richard

From: IBM Mainframe Discussion List  on behalf of 
kekronbekron <02dee3fcae33-dmarc-requ...@listserv.ua.edu>
Date: Monday, August 29, 2022 at 11:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Connect CDC SQDATA VSAM
Thank you for clarifying Richard!

Do you support IMS logs, OPERLOG/SYSLOG?

- KB

--- Original Message ---
On Monday, August 29th, 2022 at 9:59 PM, Richard Philyaw 
 wrote:


> It is true that VirtualZ allows access of VSAM (all types), PDS and PDSE, 
> QSAM/BSAM and GDGs via NFS hosted on Z as a ZiiP-eligible started task.
>
> We do not require installation of an NFS client. We work with the NFS support 
> that is already present in Linux distributions as well as the NFSV2 client 
> currently available on Windows Server distributions. We prefer NFS V4.x for 
> the performance and security benefits, so installation of a newer version 
> client on Windows is desirable, but not required.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: 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: IDC3009I & IDC1566I with a weird dsn

[Steely.Mark]

I remember at one time IBM had a free / shareware tool that could delete bad 
DSN entries. I used it a couple of times - but it has been years and I can't 
remember the name or where it is. 

I will keep looking. 

Thanks

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jack Zukt
Sent: Wednesday, August 31, 2022 8:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IDC3009I & IDC1566I with a weird dsn

ATTENTION: This e-mail came from an external source. Do not open attachments or 
click on links from unknown or unexpected emails.


Hi Carmen
Thank you for the input. I have tried IDCAMS DELETE but to no avail.
As for FDR, you are probably right. It might be something left from a job 
running FDR that ended abnormally. But considering the number of "lost"
entries, some of those jobs must have considered complete even with the errors.
Regards,
Jack

On Wed, 31 Aug 2022 at 13:58, Carmen Vitullo  wrote:

> Jack, 2 things some to mind,  have you tried to use IDCAMS to delete 
> the entry using NVR (non vsam) file
>
> DELETE FILE(DD1) -
>
> 'COMPONENT' NVR
>
> also I recall, you use FDR to compact volumes, and one volume during 
> compaction fails it leaves a 'pointer' for the lack of a better term 
> as an non standard data set name that cannot be deleted by normal 
> methods, to get rid of the file you need to run the compact job again 
> to a successful end
>
>
> Carmen
>
> On 8/31/2022 5:50 AM, Jack Zukt wrote:
> > Hi Allan,
> > This "thing" has got no description; it is not a NONVSAM nor a VSAM
> entry.
> > There is no VOLSER associared with it. I tried using IDCAMS DELETE
> NONVSAM
> > but all I got in return was
> > IDC3203I ITEM '.|.' DOES NOT ADHERE TO RESTRICTIONS. Which is 
> > not surprising considering that it does have spaces in it.
> >
> > Regards
> > Jack
> >
> >
> > On Tue, 30 Aug 2022 at 21:28, Allan Staller < 
> > 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote:
> >
> >> Classification: Confidential
> >>
> >> LISTCAT ENT(entryname) ALL
> >> Select the component (cluster index) and volume (xx)
> >>
> >> Use IDCAMS in batch:
> >> //STEP EXEC IDCAMS
> >> //SYSPRINT  DD *
> >> //DD1   DD UNIT=SYSDA,DISP=SHR,VOL=SER=xx
> >> //SYSIN DD  *
> >>   DEL componentname VVR FILE(DD1)
> >> /*
> >>
> >> HTH,
> >>
> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On
> Behalf
> >> Of Jack Zukt
> >> Sent: Tuesday, August 30, 2022 9:04 AM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: IDC3009I & IDC1566I with a weird dsn
> >>
> >> [CAUTION: This Email is from outside the Organization. Unless you 
> >> trust the sender, Don’t click links or open attachments as it may 
> >> be a
> Phishing
> >> email, which can steal your Information and compromise your 
> >> Computer.]
> >>
> >> Hi all,
> >>
> >> Another situation that come up. Is anyone of you familiar with 
> >> these
> >> messages:
> >>
> >> IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS 
> >> IGG0CLFF-5 IDC1566I ** .|. ...8..U...2. 
> >> NOT LISTED
> >>
> >> As far as I can see, there is not one dataset with such a name on 
> >> any of the available DASD. And yet I have 34 of those messages 
> >> across 7 user catalogs (and they can be there for a long time) 
> >> Aside from a RC(04) on
> the
> >> LISTCAT CAT(), there seems to be no other issue.
> >> However, I cannot find a way to get rid of those as the dataset 
> >> name
> does
> >> not adhere to restrictions.
> >> Any ideas?
> >> jack
> >>
> >> ---
> >> --- For IBM-MAIN subscribe / signoff / archive access instructions, 
> >> send
> email
> >> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >> ::DISCLAIMER::
> >> 
> >> The contents of this e-mail and any attachment(s) are confidential 
> >> and intended for the named recipient(s) only. E-mail transmission 
> >> is not guaranteed to be secure or error-free as information could 
> >> be
> intercepted,
> >> corrupted, lost, destroyed, arrive late or incomplete, or may 
> >> contain viruses in transmission. The e mail and its contents (with 
> >> or without referred errors) shall therefore not attach any 
> >> liability on the
> originator
> >> or HCL or its affiliates. Views or opinions, if any, presented in 
> >> this email are solely those of the author and may not necessarily 
> >> reflect the views or opinions of HCL or its affiliates. Any form of 
> >> reproduction, dissemination, copying, disclosure, modification, 
> >> distribution and / or publication of this message without the prior 
> >> written consent of
> authorized
> >> representative of HCL is strictly prohibited. If you have received 
> >> this email in error please delete it and notify the sender immediately.
> Before
> >> opening any email and/or attachments, please check them for viruses 
> >> and other defects.
> >> 
> >>
> >> 

Re: CA-11

[Bill Johnson]

The Control suite of products is quite good. D, M, O, IOA, etc.


Sent from Yahoo Mail for iPhone


On Wednesday, August 31, 2022, 11:19 AM, Carmen Vitullo  
wrote:

BMC's CONTROL-D IIRC, there's a CONTROL Suite that will / can replace 
all of the products

they work real well

Carmen

On 8/31/2022 10:16 AM, Steve Beaver wrote:
> Does anyone know a replacement for CA-11?
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: 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: Calculate deltas using DFSORT

[Walt Farrell]

On Wed, 31 Aug 2022 10:03:21 -0500, Paul Gilmartin  wrote:

>
>"[^abc]" matches any string containing a character
>other than a, b, or c.  It matches "wombat".  However,
>"^[^abc]*$" matches strings containing no character
>other than a, b, or c.   It does not match "wombat".

Was that something you said, or something you're quoting from the manual? I'm 
not sure.

In any case, "[^abc]" does not match "wombat". It matches only a single 
character of a string. So, it might match the "w" in "wombat", or the "o", or 
the "m", or the "t", depending on other details of the input string being 
processed, and the application doing the processing.

I agree with your comment (which I omitted from my quote) that the DFSORT books 
should not try to explain reg-ex processing, unless they have written their own 
processor instead of reusing someone else's.

-- 
Walt

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

Re: [EXTERNAL] CA-11

[Gorham, Steve]

Control-M


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Wednesday, August 31, 2022 11:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] CA-11

Does anyone know a replacement for CA-11?


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

[Carmen Vitullo]

BMC's CONTROL-D IIRC, there's a CONTROL Suite that will / can replace 
all of the products


they work real well

Carmen

On 8/31/2022 10:16 AM, Steve Beaver wrote:

Does anyone know a replacement for CA-11?


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


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

CA-11

[Steve Beaver]

Does anyone know a replacement for CA-11?


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

Re: Calculate deltas using DFSORT

[Paul Gilmartin]

On Wed, 31 Aug 2022 05:55:46 -0500, Mario Bezzi wrote:

>Sri Hari, Max, all,
>
>thank you very much from your kind help and support. 
>
>I really appreciate it, and I hope to have the opportunity to reciprocate.
> 
+1
Kolusu's assistance is priceless!


I've read on about regular expressions.  I see in the DFSORT Guide:
INCLUDE Control Statement
  The basic regular expression metacharacters are:
 ¬ $ . * \( \) [ \{ \} \

but later in a table:
[^string]

Is it "^" or "¬"?  Some clarification is needed.  I'll submit an RCF.

I hate EBCDIC!

The ISPF Edit Macros manual says that  metacharacters in regular
expressions are interpreted according to the CCSID of the controlling
terminal, listing several dozen supported CCSIDs, and says that in
background IBM-1047 is presumed.  Is this also true if DFSORT is
invoked by TSO CALL?  If SYSIN is allocated to a UNIX file tagged
with a CCSID, does DFSORT respect that CCSID?

I hate EBCDIC!

Also, in a table:
The caret symbol, when inside square brackets,
negates the characters within the square brackets.
Thus [^abc], if compared to other strings, would fail
to match any that contains even one a, b, or c.

("when inside square brackets" seems to be a restrictive
clause.  It should not be enclosed in commas.)

The "^" must be the first character inside the brackets
to have this effect.

The last sentence beginning "Thus ..." is incorrect.

"[^abc]" matches any string containing a character
other than a, b, or c.  It matches "wombat".  However,
"^[^abc]*$" matches strings containing no character
other than a, b, or c.   It does not match "wombat".

Another RCF, or the same one?

The DFSORT manual (and others) should not attempt
to explain regular expressions.  They should defer to
citing a single publication with such an explanation.

-- 
gil

--
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: ELAX DRAWDOWN??

[Carmen Vitullo]

I have heard of some strange solution names, but ELAX DRAWDOWN, nope, 
not me


Carmen

On 8/31/2022 9:04 AM, Steve Thompson wrote:

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


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

ELAX DRAWDOWN??

[Steve Thompson]

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

Re: z/OSMF - again, next issue

[Carmen Vitullo]

I use, have been using for many years the ServerPac dialog, I like it, 
it's easy to use and you get 2 very clear docs 'using the dialog' and 
'installing your order', and of course the migration guide.


I've not use CBPDO, but IIRC when I joined state Gov long ago as a 
SYSPROG they used this offering.


for products maybe its best? sure beats z/OSMF especially now that I 
have to wait for an APAR (PTF) to be applied to my system just to accept 
the json file format, that's just crazy, and there's no work around.


Carmen

On 8/31/2022 8:01 AM, Keith Gooding wrote:

Why would anyone use CBPDO + SMP/E to install z/OS ? (Not a rhetorical 
question).

Z/OSMF Serverpac installation is good but you may not want to use a Serverpac 
to install a single product such as z/secure.

Keith

  


On 31 Aug 2022, at 13:09, Carmen Vitullo  wrote:

thanks for that info Art, My teammate is not real familiar  with SHOP Z and 
the options available.

she told me trying to order as CBPDO gave her an error, I'll work with her some 
more to see why

again thanks

Carmen


On 8/31/2022 4:59 AM, Art Gutowski wrote:
On Tue, 30 Aug 2022 08:01:53 -0500, Carmen Vitullo  wrote:

>from what I was told by my teammate, Zsecure version 2.5 requires

z/osmf, I could be wrong, she could be mistaken, but the issues she's
having I think would affect Serverpac, or whatever it's called now,
build JCL and submit JCL.

my case I opened was initially on the errors we were seeing on the
submit errors, that was not addressed, just the easy stuff, now I have
to recreate the issue again and make sure I have the correct error
message for support. typical of z/osmf support; my first case I opened
for z/osmf issues was open and not resolved for 364 days, so, so far I'm
ahead of the game I support

Carmen

I installed zSecure 2.5 with CBPDO and SMP/E using ISPF just fine.  No issues.  
CBPDO is available for products, and for z/OS itself, and as far as I'm aware, 
no timeline has been announced for phasing it out.  If you like z/OSMF, use it; 
if you prefer ISPF and SMP/E, use CBPDO...it's really not that difficult.

Art Gutowski
Mainframe Engineer
Huntington National Bank
arthur.gutow...@huntington.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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: 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: more locks in IRLM

[Massimo Biancucci]

Jason,

your question is really generic and I think you're talking about DB2 locks.

To obtain a lock DB2 must use CPU so the more locks the more CPU you need.
This usually is related to a workload growth or application change.

If the number of locks is quite the same and the number of lock contentions
should increase and you need to investigate if it could increase CPU usage
then it's possible (or better sure) because the lock contention management
burns CPU too.
The larger is the number of locks and the longer is the queue on a given
resource then the more CPU DB2 needs to manage it.

If the happening is so hard to make you ask a question you can give us some
other lights.
Maybe it's a good question for DB2 list.
If you're in a Data Sharing environment it can be worst.

Best regards.



[image: width=]

Privo
di virus.www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Il giorno mer 31 ago 2022 alle ore 14:51 Jason Cai  ha
scritto:

> Hi all
>
>  If there are more locks in IRLM by TRANS, will  it make CICS address
> space or DB2 address space CPU increases or decrease?
>
> Any suggestions is great appreciated!
>
> Thanks a lot!
>
> Jason Cai
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: z/OSMF - again, next issue

[Keith Gooding]

Why would anyone use CBPDO + SMP/E to install z/OS ? (Not a rhetorical 
question).

Z/OSMF Serverpac installation is good but you may not want to use a Serverpac 
to install a single product such as z/secure.

Keith

 

> On 31 Aug 2022, at 13:09, Carmen Vitullo  wrote:
> 
> thanks for that info Art, My teammate is not real familiar  with SHOP Z and 
> the options available.
> 
> she told me trying to order as CBPDO gave her an error, I'll work with her 
> some more to see why
> 
> again thanks
> 
> Carmen
> 
>> On 8/31/2022 4:59 AM, Art Gutowski wrote:
>> On Tue, 30 Aug 2022 08:01:53 -0500, Carmen Vitullo  
>> wrote:
>> 
>> >from what I was told by my teammate, Zsecure version 2.5 requires
>>> z/osmf, I could be wrong, she could be mistaken, but the issues she's
>>> having I think would affect Serverpac, or whatever it's called now,
>>> build JCL and submit JCL.
>>> 
>>> my case I opened was initially on the errors we were seeing on the
>>> submit errors, that was not addressed, just the easy stuff, now I have
>>> to recreate the issue again and make sure I have the correct error
>>> message for support. typical of z/osmf support; my first case I opened
>>> for z/osmf issues was open and not resolved for 364 days, so, so far I'm
>>> ahead of the game I support
>>> 
>>> Carmen
>> I installed zSecure 2.5 with CBPDO and SMP/E using ISPF just fine.  No 
>> issues.  CBPDO is available for products, and for z/OS itself, and as far as 
>> I'm aware, no timeline has been announced for phasing it out.  If you like 
>> z/OSMF, use it; if you prefer ISPF and SMP/E, use CBPDO...it's really not 
>> that difficult.
>> 
>> Art Gutowski
>> Mainframe Engineer
>> Huntington National Bank
>> arthur.gutow...@huntington.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

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

Re: IDC3009I & IDC1566I with a weird dsn

[Jack Zukt]

Hi Carmen
Thank you for the input. I have tried IDCAMS DELETE but to no avail.
As for FDR, you are probably right. It might be something left from a job
running FDR that ended abnormally. But considering the number of "lost"
entries, some of those jobs must have considered complete even with the
errors.
Regards,
Jack

On Wed, 31 Aug 2022 at 13:58, Carmen Vitullo  wrote:

> Jack, 2 things some to mind,  have you tried to use IDCAMS to delete the
> entry using NVR (non vsam) file
>
> DELETE FILE(DD1) -
>
> 'COMPONENT' NVR
>
> also I recall, you use FDR to compact volumes, and one volume during
> compaction fails it leaves a 'pointer' for the lack of a better term as
> an non standard data set name that cannot be deleted by normal methods,
> to get rid of the file you need to run the compact job again to a
> successful end
>
>
> Carmen
>
> On 8/31/2022 5:50 AM, Jack Zukt wrote:
> > Hi Allan,
> > This "thing" has got no description; it is not a NONVSAM nor a VSAM
> entry.
> > There is no VOLSER associared with it. I tried using IDCAMS DELETE
> NONVSAM
> > but all I got in return was
> > IDC3203I ITEM '.|.' DOES NOT ADHERE TO RESTRICTIONS. Which is not
> > surprising considering that it does have spaces in it.
> >
> > Regards
> > Jack
> >
> >
> > On Tue, 30 Aug 2022 at 21:28, Allan Staller <
> > 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote:
> >
> >> Classification: Confidential
> >>
> >> LISTCAT ENT(entryname) ALL
> >> Select the component (cluster index) and volume (xx)
> >>
> >> Use IDCAMS in batch:
> >> //STEP EXEC IDCAMS
> >> //SYSPRINT  DD *
> >> //DD1   DD UNIT=SYSDA,DISP=SHR,VOL=SER=xx
> >> //SYSIN DD  *
> >>   DEL componentname VVR FILE(DD1)
> >> /*
> >>
> >> HTH,
> >>
> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On
> Behalf
> >> Of Jack Zukt
> >> Sent: Tuesday, August 30, 2022 9:04 AM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: IDC3009I & IDC1566I with a weird dsn
> >>
> >> [CAUTION: This Email is from outside the Organization. Unless you trust
> >> the sender, Don’t click links or open attachments as it may be a
> Phishing
> >> email, which can steal your Information and compromise your Computer.]
> >>
> >> Hi all,
> >>
> >> Another situation that come up. Is anyone of you familiar with these
> >> messages:
> >>
> >> IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS IGG0CLFF-5
> >> IDC1566I ** .|. ...8..U...2. NOT LISTED
> >>
> >> As far as I can see, there is not one dataset with such a name on any of
> >> the available DASD. And yet I have 34 of those messages across 7 user
> >> catalogs (and they can be there for a long time) Aside from a RC(04) on
> the
> >> LISTCAT CAT(), there seems to be no other issue.
> >> However, I cannot find a way to get rid of those as the dataset name
> does
> >> not adhere to restrictions.
> >> Any ideas?
> >> jack
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email
> >> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >> ::DISCLAIMER::
> >> 
> >> The contents of this e-mail and any attachment(s) are confidential and
> >> intended for the named recipient(s) only. E-mail transmission is not
> >> guaranteed to be secure or error-free as information could be
> intercepted,
> >> corrupted, lost, destroyed, arrive late or incomplete, or may contain
> >> viruses in transmission. The e mail and its contents (with or without
> >> referred errors) shall therefore not attach any liability on the
> originator
> >> or HCL or its affiliates. Views or opinions, if any, presented in this
> >> email are solely those of the author and may not necessarily reflect the
> >> views or opinions of HCL or its affiliates. Any form of reproduction,
> >> dissemination, copying, disclosure, modification, distribution and / or
> >> publication of this message without the prior written consent of
> authorized
> >> representative of HCL is strictly prohibited. If you have received this
> >> email in error please delete it and notify the sender immediately.
> Before
> >> opening any email and/or attachments, please check them for viruses and
> >> other defects.
> >> 
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO 

Re: IDC3009I & IDC1566I with a weird dsn

[Carmen Vitullo]

Jack, 2 things some to mind,  have you tried to use IDCAMS to delete the 
entry using NVR (non vsam) file


DELETE FILE(DD1) -

   'COMPONENT' NVR

also I recall, you use FDR to compact volumes, and one volume during 
compaction fails it leaves a 'pointer' for the lack of a better term as 
an non standard data set name that cannot be deleted by normal methods, 
to get rid of the file you need to run the compact job again to a 
successful end



Carmen

On 8/31/2022 5:50 AM, Jack Zukt wrote:

Hi Allan,
This "thing" has got no description; it is not a NONVSAM nor a VSAM entry.
There is no VOLSER associared with it. I tried using IDCAMS DELETE NONVSAM
but all I got in return was
IDC3203I ITEM '.|.' DOES NOT ADHERE TO RESTRICTIONS. Which is not
surprising considering that it does have spaces in it.

Regards
Jack


On Tue, 30 Aug 2022 at 21:28, Allan Staller <
0387911dea17-dmarc-requ...@listserv.ua.edu> wrote:


Classification: Confidential

LISTCAT ENT(entryname) ALL
Select the component (cluster index) and volume (xx)

Use IDCAMS in batch:
//STEP EXEC IDCAMS
//SYSPRINT  DD *
//DD1   DD UNIT=SYSDA,DISP=SHR,VOL=SER=xx
//SYSIN DD  *
  DEL componentname VVR FILE(DD1)
/*

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf
Of Jack Zukt
Sent: Tuesday, August 30, 2022 9:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IDC3009I & IDC1566I with a weird dsn

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

Hi all,

Another situation that come up. Is anyone of you familiar with these
messages:

IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS IGG0CLFF-5
IDC1566I ** .|. ...8..U...2. NOT LISTED

As far as I can see, there is not one dataset with such a name on any of
the available DASD. And yet I have 34 of those messages across 7 user
catalogs (and they can be there for a long time) Aside from a RC(04) on the
LISTCAT CAT(), there seems to be no other issue.
However, I cannot find a way to get rid of those as the dataset name does
not adhere to restrictions.
Any ideas?
jack

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

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


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


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: 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: Automation of the TSO RECEIVE command

[Paul Gilmartin]

On Wed, 31 Aug 2022 11:12:12 +0100, Lennie Dymoke-Bradshaw wrote:

>The TSO commands TRANSMIT and RECEIVE are very useful for moving data
>around, particularly as TRANSMIT produces an 80-byte LRECL which works
>easily with in-stream JCL.
> 
But there's a hazard.  The encoded data might by happenstance contain "//" in
the first two positions of a record, breaking the in-stream data set.  You can
demonstrate this by TRANSMITting a file containing many "/" characters.

It's safer if you use "DATA,DLM='U5ZMw0Di'", for example in JES2.  In JES3,
you're SOL.

( I used "head -c6 /dev/random | uuencode -m x".)

-- 
gil

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

more locks in IRLM

[Jason Cai]

Hi all
  
 If there are more locks in IRLM by TRANS, will  it make CICS address space or 
DB2 address space CPU increases or decrease?

Any suggestions is great appreciated!

Thanks a lot!

Jason Cai

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

Re: z/OSMF - again, next issue

[Carmen Vitullo]

thanks for that info Art, My teammate is not real familiar  with SHOP Z 
and the options available.


she told me trying to order as CBPDO gave her an error, I'll work with 
her some more to see why


again thanks

Carmen

On 8/31/2022 4:59 AM, Art Gutowski wrote:

On Tue, 30 Aug 2022 08:01:53 -0500, Carmen Vitullo  wrote:

>from what I was told by my teammate, Zsecure version 2.5 requires

z/osmf, I could be wrong, she could be mistaken, but the issues she's
having I think would affect Serverpac, or whatever it's called now,
build JCL and submit JCL.

my case I opened was initially on the errors we were seeing on the
submit errors, that was not addressed, just the easy stuff, now I have
to recreate the issue again and make sure I have the correct error
message for support. typical of z/osmf support; my first case I opened
for z/osmf issues was open and not resolved for 364 days, so, so far I'm
ahead of the game I support

Carmen

I installed zSecure 2.5 with CBPDO and SMP/E using ISPF just fine.  No issues.  
CBPDO is available for products, and for z/OS itself, and as far as I'm aware, 
no timeline has been announced for phasing it out.  If you like z/OSMF, use it; 
if you prefer ISPF and SMP/E, use CBPDO...it's really not that difficult.

Art Gutowski
Mainframe Engineer
Huntington National Bank
arthur.gutow...@huntington.com

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


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

Re: Automation of the TSO RECEIVE command

[Robin Atwood]

If you are using Rexx call the "queue" function to stack the response before
you issue RECEIVE. Also make sure you have called "prompt('ON')".

HTH
Robin

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Lennie Dymoke-Bradshaw
Sent: 31 August 2022 17:12
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Automation of the TSO RECEIVE command

The TSO commands TRANSMIT and RECEIVE are very useful for moving data
around, particularly as TRANSMIT produces an 80-byte LRECL which works
easily with in-stream JCL.

But has anyone worked out a reliable mechanism to automate the use of the
RECEIVE command?

It always issues queries to the user. How can the responses to these queries
be simply handled?

I feel sure someone has worked this out.

 



Lennie Dymoke-Bradshaw

https://rsclweb.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

Re: Automation of the TSO RECEIVE command

[Peter Vels]

Just put the response on the next line of the input:

RECEIVE INDSN('bla.XMIT')
DATASET('bla.LOAD')


On Wed, 31 Aug 2022, 20:19 Lennie Dymoke-Bradshaw, <
032fff1be9b4-dmarc-requ...@listserv.ua.edu> wrote:

> The TSO commands TRANSMIT and RECEIVE are very useful for moving data
> around, particularly as TRANSMIT produces an 80-byte LRECL which works
> easily with in-stream JCL.
>
> But has anyone worked out a reliable mechanism to automate the use of the
> RECEIVE command?
>
> It always issues queries to the user. How can the responses to these
> queries
> be simply handled?
>
> I feel sure someone has worked this out.
>
>
>
>
>
> Lennie Dymoke-Bradshaw
>
> https://rsclweb.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

Re: Calculate deltas using DFSORT

[Mario Bezzi]

Sri Hari, Max, all,

thank you very much from your kind help and support. 

I really appreciate it, and I hope to have the opportunity to reciprocate.

mario

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

Re: IDC3009I & IDC1566I with a weird dsn

[Jack Zukt]

Hi Allan,
This "thing" has got no description; it is not a NONVSAM nor a VSAM entry.
There is no VOLSER associared with it. I tried using IDCAMS DELETE NONVSAM
but all I got in return was
IDC3203I ITEM '.|.' DOES NOT ADHERE TO RESTRICTIONS. Which is not
surprising considering that it does have spaces in it.

Regards
Jack


On Tue, 30 Aug 2022 at 21:28, Allan Staller <
0387911dea17-dmarc-requ...@listserv.ua.edu> wrote:

> Classification: Confidential
>
> LISTCAT ENT(entryname) ALL
> Select the component (cluster index) and volume (xx)
>
> Use IDCAMS in batch:
> //STEP EXEC IDCAMS
> //SYSPRINT  DD *
> //DD1   DD UNIT=SYSDA,DISP=SHR,VOL=SER=xx
> //SYSIN DD  *
>  DEL componentname VVR FILE(DD1)
> /*
>
> HTH,
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Jack Zukt
> Sent: Tuesday, August 30, 2022 9:04 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IDC3009I & IDC1566I with a weird dsn
>
> [CAUTION: This Email is from outside the Organization. Unless you trust
> the sender, Don’t click links or open attachments as it may be a Phishing
> email, which can steal your Information and compromise your Computer.]
>
> Hi all,
>
> Another situation that come up. Is anyone of you familiar with these
> messages:
>
> IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS IGG0CLFF-5
> IDC1566I ** .|. ...8..U...2. NOT LISTED
>
> As far as I can see, there is not one dataset with such a name on any of
> the available DASD. And yet I have 34 of those messages across 7 user
> catalogs (and they can be there for a long time) Aside from a RC(04) on the
> LISTCAT CAT(), there seems to be no other issue.
> However, I cannot find a way to get rid of those as the dataset name does
> not adhere to restrictions.
> Any ideas?
> jack
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> ::DISCLAIMER::
> 
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only. E-mail transmission is not
> guaranteed to be secure or error-free as information could be intercepted,
> corrupted, lost, destroyed, arrive late or incomplete, or may contain
> viruses in transmission. The e mail and its contents (with or without
> referred errors) shall therefore not attach any liability on the originator
> or HCL or its affiliates. Views or opinions, if any, presented in this
> email are solely those of the author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction,
> dissemination, copying, disclosure, modification, distribution and / or
> publication of this message without the prior written consent of authorized
> representative of HCL is strictly prohibited. If you have received this
> email in error please delete it and notify the sender immediately. Before
> opening any email and/or attachments, please check them for viruses and
> other defects.
> 
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: IDC3009I & IDC1566I with a weird dsn

[Jack Zukt]

Hi Joe,

Thank you for you input.  I had seen that.We are running 2.4 in which that
APAR PTF  (UJ00743) has already been SUP (UJ02056)
I have 34 pairs of those messages for 7 usercats, on a job that lists 66
usercats. I think that if this was a bug t would affect all the listcats.
I do not know how these entries got there. Probably some utility that did
not end as expected. But as the "dataset name" does not adhere to MVS
rules, I cannot find a way to get ride of them.
Regards
Jack


On Tue, 30 Aug 2022 at 17:36, Joe Monk  wrote:

> Might be this: https://www.ibm.com/support/pages/apar/OA57619
>
> Users of CSI and LISTCAT Level may receive inconsistent errors
> on entries that have no problem otherwise due to uninitialized
> workarea data.
>
>
> Joe
>
> On Tue, Aug 30, 2022 at 9:04 AM Jack Zukt  wrote:
>
> > Hi all,
> >
> > Another situation that come up. Is anyone of you familiar with these
> > messages:
> >
> > IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS IGG0CLFF-5
> > IDC1566I ** .|. ...8..U...2. NOT LISTED
> >
> > As far as I can see, there is not one dataset with such a name on any of
> > the available DASD. And yet I have 34 of those messages across 7 user
> > catalogs (and they can be there for a long time)
> > Aside from a RC(04) on the LISTCAT CAT(), there seems to be no other
> issue.
> > However, I cannot find a way to get rid of those as the dataset name does
> > not adhere to restrictions.
> > Any ideas?
> > 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

Automation of the TSO RECEIVE command

[Lennie Dymoke-Bradshaw]

The TSO commands TRANSMIT and RECEIVE are very useful for moving data
around, particularly as TRANSMIT produces an 80-byte LRECL which works
easily with in-stream JCL.

But has anyone worked out a reliable mechanism to automate the use of the
RECEIVE command?

It always issues queries to the user. How can the responses to these queries
be simply handled?

I feel sure someone has worked this out.

 



Lennie Dymoke-Bradshaw

https://rsclweb.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

Re: Calculate deltas using DFSORT

[Andrew Rowley]

On 31/08/2022 10:02 am, Paul Gilmartin wrote:

The DFSORT command syntax is dreadful -- too positional.  It's
hard to read ...,keyword,value,keyword,value,...
Considerably better would be ,keyword(value), or ,keyword=value,...


I'm not sure that it is that bad for defining a sort, but it does get 
complex when it is extended to do other tasks.


There seem to be various "tricks" used which work, but are not exactly 
intuitive.


Andrew Rowley
Black Hill Sofware

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

Re: z/OSMF - again, next issue

[Art Gutowski]

On Tue, 30 Aug 2022 08:01:53 -0500, Carmen Vitullo  wrote:

>from what I was told by my teammate, Zsecure version 2.5 requires
>z/osmf, I could be wrong, she could be mistaken, but the issues she's
>having I think would affect Serverpac, or whatever it's called now,
>build JCL and submit JCL.
>
>my case I opened was initially on the errors we were seeing on the
>submit errors, that was not addressed, just the easy stuff, now I have
>to recreate the issue again and make sure I have the correct error
>message for support. typical of z/osmf support; my first case I opened
>for z/osmf issues was open and not resolved for 364 days, so, so far I'm
>ahead of the game I support
>
>Carmen

I installed zSecure 2.5 with CBPDO and SMP/E using ISPF just fine.  No issues.  
CBPDO is available for products, and for z/OS itself, and as far as I'm aware, 
no timeline has been announced for phasing it out.  If you like z/OSMF, use it; 
if you prefer ISPF and SMP/E, use CBPDO...it's really not that difficult.

Art Gutowski
Mainframe Engineer
Huntington National Bank
arthur.gutow...@huntington.com

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