Re: IWS Agent for z/OS - SSL Configuration

[Timothy Sipples]

Gilson,

Does the information here help?

1. 
https://www.ibm.com/docs/en/workload-automation/10.1.0?topic=ssae-enabling-fips-compliance-over-z-workload-scheduler-server-ssl-secured-connection
2. 
https://www.ibm.com/docs/en/workload-automation/10.1.0?topic=server-configuring-tls-connect-z-workload-scheduler#configTLS

— — — — —
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM zSystems/LinuxONE, Asia-Pacific
sipp...@sg.ibm.com


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

Re: z/OSMF again

[Kurt J. Quackenbush]

> There are 2 missing icons that I need - Software Management  & Software 
> Updates.

> I been through several manuals and have performed additional setup and SAF 
> rules that are suppose to provide this function.

Did you check the "App Center" folder in the lower left corner of the z/OSMF 
desktop?  I don't know why, but some application icons do not get displayed on 
the desktop by default, but you can drag them from the App Center folder to the 
desktop.  If they are not in the App Center folder then I suggest open a 
support case.

Kurt Quackenbush
IBM  |  z/OS SMP/E and z/OSMF Software Management  |  ku...@us.ibm.com

Chuck Norris never uses CHECK when he applies PTFs.

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

z/OSMF again

[Steely.Mark]

When I logon to z/OSMF all I see is 16 ICONS.

There are 2 missing icons that I need - Software Management  & Software Updates.

I been through several manuals and have performed additional setup and SAF 
rules that are suppose to provide this function.

Any ideas of what I can check first ?

Open a case with IBM is the next step.

We are z/OS v2.4 and I have a product to install that is only delivered z/OSMF 
format from IBM.

Any help would be appreciated.

Thank You


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

IWS Agent for z/OS - SSL Configuration

[Gilson Cesar de Oliveira]

Hi everyone,

We are facing some issues regarding IWS Agent for z/OS where we have
to configure HTTPOPTS but for this option there is no way to restrict the
encryption protocol for TLSv1.2 only.

All they have available to configure are the following:

>--+---+>
   | .-CAONLY-.|   
   '-SSLAUTHMODE--(--+-STRING-+--)-'   

>--+-+-->
   |   .-tws.|   
   '-SSLAUTHSTRING--(--+-SSL string-+--)-'   

>--++--->
   '-SSLKEYRING--(SSL key ring db filename)-'   

>--++--->
   '-SSLKEYRINGPSW--(SSL key ring psw filename)-'   

>--+---+>
   |.-SAF-.|   
   '-SSLKEYRINGTYPE--(--+-USS-+--)-'   

>--++--->
   | .-512-.|   
   '-SSLPORT--(--+-SSL port number-+--)-'

We have to fix all the issues related to the vulnerabilities but for this
service it looks like there is no solution available for it.

Does anyone that already have problems with it would suggest a way to do it
??

Pagent would be an alternative viable to implement ??

Thanks in advance for any help.

Gilson   

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

New SHARE App on iOS?

[Michael Babcock]

There’s supposed to be a new SHARE app on iOS but the App Store cannot find
it.  Anyone know when it will be available in the US?--
Michael Babcock
OneMain Financial
z/OS Systems Programmer, Lead

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

Re: z/OS 1.4 submit

[Seymour J Metz]

ObPinkPanther "You said your dog doesn't bite!"   -   "It's not my dog."

If you prefer a different metaphor "Not my monkeys, not my circus."


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, July 20, 2022 12:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 1.4 submit

On Wed, 20 Jul 2022 12:06:27 +, Seymour J Metz wrote:

>I can't speak for others, but if the reference manual for the command doesn't 
>explicitly show support for ddname or dsn then I won't use that syntax in 
>production even if I've tested it and it works, although I would submit an 
>RCF. But it's not my dog; do as you wish.
>
I suspect the RCF has been tried often, and that IBM's riposte, tacit or overt, 
is that they
prefer not to commit to supporting all possible variants.

If they had the courage, utilities documented as having a "file" parameter 
would do
not fopen( file ) but fdopen( open( file ) ) and report errors.

(Isn't the metaphor you intend "I don't have a dog in this fight"?
)

--
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: z/OS 1.4 submit

[Paul Gilmartin]

On Wed, 20 Jul 2022 12:06:27 +, Seymour J Metz wrote:

>I can't speak for others, but if the reference manual for the command doesn't 
>explicitly show support for ddname or dsn then I won't use that syntax in 
>production even if I've tested it and it works, although I would submit an 
>RCF. But it's not my dog; do as you wish.
> 
I suspect the RCF has been tried often, and that IBM's riposte, tacit or overt, 
is that they
prefer not to commit to supporting all possible variants.

If they had the courage, utilities documented as having a "file" parameter 
would do
not fopen( file ) but fdopen( open( file ) ) and report errors.

(Isn't the metaphor you intend "I don't have a dog in this fight"?
)

-- 
gil

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

Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS macro name IDENTIFY

[Paul Gilmartin]

On Wed, 20 Jul 2022 14:26:26 +, Farley, Peter x23353 wrote:

>Update: I have followed up with John Tilling over on CICS-L about this.  The 
>member named IDENTIFY in our local CICS MACLIB looks like it may be an 
>artifact of the product delivery or build mechanism, and may not have been 
>intended to be left there.  Not sure at this point if IBM or the local product 
>maintenance team are the ones who need to address why it is there and how to 
>remove it.
>
Someone may be using it.

IBM registers component prefixes for ISV use.  The scope is to small.  For 
example, SYSMOD IDs are
not covered.  Does IBM guarantee that no macro or opcode will ever conflict 
with a registered
ISV prefix?

In the real world, not constrained by an archaic name space, there appears to 
be a convention
(standard?) of using a registered domain name as a qualifier.  On my laptop, 
for example,
I find:
com.Google.
com.adobe.
com.apple.
com.microsoft.
com.oracle.java.
etc.  Dozens, at least.

-- 
gil

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

Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS macro name IDENTIFY

[Charles Mills]

You're right, aren't you? 

There would be no need for IBM to touch the opcode logic to support
ddname.IDENTIFY or anything like that. IBM could do the trick with a simple
(well, simple for me to say) enhancement to COPY to allow ddname(member) or
whatever equivalent syntax made sense to IBM.

A macro copied into the source code comes ahead of SYSLIB in the search
order, right? So copying the right IDENTIFY at the start of the source code
would solve the problem, right?

(And yes, I know the OP's error has been resolved: the CICS IDENTIFY in
question is spurious.)

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Wednesday, July 20, 2022 5:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS
macro name IDENTIFY

There is no COPY ddname(member) in HLASM. That sounds like an obvious
candidate for an RFE.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Charles Mills [charl...@mcn.org]
Sent: Tuesday, July 19, 2022 5:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS
macro name IDENTIFY

In COBOL you can say COPY member OF ddname, so you can get an instance of
'member' that is not the first one in SYSLIB. PL/I has something similar.

I don't think there is any way to do that in HLASM, is there? That would be
nice.

Perhaps a *PROCESS option to say "find macro IDENTIFY in the SYSMAC
concatenation." (And then you would provide a SYSMAC DD statement pointing
to SYS1.MACLIB or similar.) Or a hierarchical opcode name scheme like
SYSMAC.IDENTIFY.

Classic name collision problem. Many languages provide some way to control
namespaces at the individual source code level.

If IDENTIFY had been invented today they would have been called IEFIDENT and
DFHIDENT, thereby solving the problem (but at a cost in memorability).

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Farley, Peter x23353
Sent: Tuesday, July 19, 2022 2:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Name conflict: CICS macro name IDENTIFY conflicts with MVS macro
name IDENTIFY

Cross-posted to IBM-MAIN and CICS-L.

We just encountered this.  Our SDLC mechanism has CICS.BASE.MACLIB (an ALIAS
for the current product version library) positioned in the assembler
translate step BEFORE the SYS1.MACLIB library.  SOP, put all licensed
product libraries ahead of base system libraries, right?

Not in this case.  Turns out we have some old assembler ode that uses the
MVS IDENTIFY macro for reasonable business purposes, but now the CICS MACLIB
ALSO has a macro named IDENTIFY.

Now that assembler program cannot be maintained or changed until the SYSLIB
setup in the SDLC mechanism is updated (never a short process).

The obvious solution here is of course to change the SDLC setup to put the
CICS MACLIB after SYS1.MACLIB, but was this documented to the sysprogs that
there is a (new?) name conflict here?

Do the CICS and MVS sysprogs even talk to each other or to the SDLC
mechanism maintainers?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: 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: Using DFSORT to display binary and Packed Decimal values

[Jack Zukt]

Thanks Kolusu
Jack

On Wed, 20 Jul 2022 at 15:53, Sri h Kolusu  wrote:

> Jack,
>
> The link that nigel pointed out is an old one and does not have the
> updated the macros (encryption and other enhancements). Moreover the FTP
> link also does not work. I will fix the website not to refer to the FTP
> site.
>
>  I will respond to you offline about the updated macros and JCL.
>
>
> Thanks,
> Kolusu
> DFSORT Development
> IBM Corporation
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Using DFSORT to display binary and Packed Decimal values

[Sri h Kolusu]

Jack,

The link that nigel pointed out is an old one and does not have the updated the 
macros (encryption and other enhancements). Moreover the FTP link also does not 
work. I will fix the website not to refer to the FTP site.

 I will respond to you offline about the updated macros and JCL.


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: DFSORT/ICETOOL

[Jack Zukt]

Hello Kolusu,

Now I am feeling stupid. I should have been able to figure that out.
Thank you again for your help.
Best wishes,
Jack

On Wed, 20 Jul 2022 at 15:23, Sri h Kolusu  wrote:

> >>. There is a small glitch and I can not understand why: the year, on the
> output, has only the three leftmost positions:
>
> Jack,
>
> It is NOT a glitch. Your Input is FBA which has the carriage control and
> since I am writing to SDSF with SORTOUT DD SYSOUT=* , it is NOT showing the
> carriage control. So you just press PF10 and you should be able to see it.
>
> Alternatively you can code RECFM=FB on the SORTOUT dd statement.
>
> SORTOUT DD SYSOUT=*,RECFM=FB
>
>
> Thanks,
> Kolusu
> DFSORT Development
> IBM Corporation
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS macro name IDENTIFY

[Farley, Peter x23353]

Update: I have followed up with John Tilling over on CICS-L about this.  The 
member named IDENTIFY in our local CICS MACLIB looks like it may be an artifact 
of the product delivery or build mechanism, and may not have been intended to 
be left there.  Not sure at this point if IBM or the local product maintenance 
team are the ones who need to address why it is there and how to remove it.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Joe 
Monk
Sent: Wednesday, July 20, 2022 10:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS macro 
name IDENTIFY

Moreover, a CICS macro would start with DFH... it wouldnt be called
IDENTIFY.

Joe

On Wed, Jul 20, 2022 at 8:41 AM Ward Able, Grant  wrote:

> As stated by IBM Hursley (John Tilling) on the CICS-List,  CICS does not
> ship an IDENTIFY macro!
>
> Regards - Grant.
> Telephone Internal: 201496 (London)
>
> EAM - Enterprise Application Middleware
>
> In theory, there's no difference between theory and practice. In practice,
> there is.
>
> Worry more about your character than your reputation.  Character is what
> you are, reputation merely what others think you are. - John Wooden
>
> If you don't have time to do it right, when will you have the time to do
> it over? - John Wooden
>
>
>
> DTCC Public (White)
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Seymour J Metz
> Sent: 20 July 2022 14:18
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS
> macro name IDENTIFY
>
> ATTENTION: External Email - Be Suspicious of Attachments, Links and
> Requests for Login Information.
>
> IDENTIFY has existed and been documented since Old Man Noach got high on
> PCP. Yes, CICS should have known better.
>
> The RFE wouldn't be for unique names; that ship has sailed. It would be
> for new syntax on COPY.
>
> If your program needs both, you're screwed. Welcome to CM Hell.
>
> --
> Shmuel (Seymour J.) Metz
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
> Sent: Wednesday, July 20, 2022 9:11 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS
> macro name IDENTIFY
>
> On Wed, 20 Jul 2022 12:18:56 +, Seymour J Metz wrote:
>
> >There is no COPY ddname(member) in HLASM. That sounds like an obvious
> candidate for an RFE.
> >
> Hasn't the MVS macro name IDENTIFY existed long enough that CICS should
> have known better?
>
> That's not an RFE; tt's a bug; BAD.  Suppose a program needs both services.
>
>
> >-Original Message-
> >From: Farley, Peter x23353
> >Sent: Tuesday, July 19, 2022 2:07 PM
> >
> >Cross-posted to IBM-MAIN and CICS-L.
> >
> >We just encountered this.  Our SDLC mechanism has CICS.BASE.MACLIB (an
> >ALIAS for the current product version library) positioned in the
> >assembler translate step BEFORE the SYS1.MACLIB library.  SOP, put all
> >licensed product libraries ahead of base system libraries, right?
> >
> >Not in this case.  Turns out we have some old assembler ode that uses
> >the MVS IDENTIFY macro for reasonable business purposes, but now the
> >CICS MACLIB ALSO has a macro named IDENTIFY.
--

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: DFSORT/ICETOOL

[Sri h Kolusu]

>>. There is a small glitch and I can not understand why: the year, on the 
>>output, has only the three leftmost positions:

Jack,

It is NOT a glitch. Your Input is FBA which has the carriage control and since 
I am writing to SDSF with SORTOUT DD SYSOUT=* , it is NOT showing the carriage 
control. So you just press PF10 and you should be able to see it.

Alternatively you can code RECFM=FB on the SORTOUT dd statement.

SORTOUT DD SYSOUT=*,RECFM=FB


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: Using DFSORT to display binary and Packed Decimal values

[Jack Zukt]

Thank you Nigel,

I am going to have a look at it,

Regards,
Jack

On Wed, 20 Jul 2022 at 15:11, Nigel Morton  wrote:

> I thought I had a job that did exactly this but I can't find it. However,
> there are plenty of examples indexed at
> https://www.ibm.com/support/pages/dfsort-icetool-papers-and-examples
> including for DCOLLECT.
>
> On Wed, 20 Jul 2022 at 11:43, Jack Zukt  wrote:
>
> > Hi,
> >
> > I am using DFSORT to process DCOLLECT Data Records. I am trying to
> format a
> > output record with the dataset name, volser, allocated space, creation
> date
> > and last ref date.
> > On the DCOLLECT Data Record, the allocated space is on a binary format
> and
> > the date fields are all on packed decimal. I would like those to be
> > reformatted to a character format as I want it to be readable. So far I
> > have been reading the manual and have been on a trial and error process,
> > with a lot of tries and a lot of errors.  As this must be a simple thing
> to
> > do, I must be doing it all wrong.
> > Ant help will be greatly appreciated,
> > Best regards,
> > Jack
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS macro name IDENTIFY

[Joe Monk]

Moreover, a CICS macro would start with DFH... it wouldnt be called
IDENTIFY.

Joe

On Wed, Jul 20, 2022 at 8:41 AM Ward Able, Grant  wrote:

> As stated by IBM Hursley (John Tilling) on the CICS-List,  CICS does not
> ship an IDENTIFY macro!
>
> Regards - Grant.
> Telephone Internal: 201496 (London)
>
> EAM - Enterprise Application Middleware
>
> In theory, there's no difference between theory and practice. In practice,
> there is.
>
> Worry more about your character than your reputation.  Character is what
> you are, reputation merely what others think you are. - John Wooden
>
> If you don't have time to do it right, when will you have the time to do
> it over? - John Wooden
>
>
>
> DTCC Public (White)
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Seymour J Metz
> Sent: 20 July 2022 14:18
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS
> macro name IDENTIFY
>
> ATTENTION: External Email - Be Suspicious of Attachments, Links and
> Requests for Login Information.
>
> IDENTIFY has existed and been documented since Old Man Noach got high on
> PCP. Yes, CICS should have known better.
>
> The RFE wouldn't be for unique names; that ship has sailed. It would be
> for new syntax on COPY.
>
> If your program needs both, you're screwed. Welcome to CM Hell.
>
>
> --
> Shmuel (Seymour J.) Metz
>
> https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3data=05%7C01%7Cgwardable%40DTCC.COM%7C84a10466544949519ea508da6a5254cd%7C0465519d7f554d47998b55e2a86f04a8%7C0%7C0%7C637939199102819262%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=RmTDzrKLqfpMeWzgN3LzujQbqe9CNNgHDschdGnwYwY%3Dreserved=0
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
> Sent: Wednesday, July 20, 2022 9:11 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS
> macro name IDENTIFY
>
> On Wed, 20 Jul 2022 12:18:56 +, Seymour J Metz wrote:
>
> >There is no COPY ddname(member) in HLASM. That sounds like an obvious
> candidate for an RFE.
> >
> Hasn't the MVS macro name IDENTIFY existed long enough that CICS should
> have known better?
>
> That's not an RFE; tt's a bug; BAD.  Suppose a program needs both services.
>
>
> >-Original Message-
> >From: Farley, Peter x23353
> >Sent: Tuesday, July 19, 2022 2:07 PM
> >
> >Cross-posted to IBM-MAIN and CICS-L.
> >
> >We just encountered this.  Our SDLC mechanism has CICS.BASE.MACLIB (an
> >ALIAS for the current product version library) positioned in the
> >assembler translate step BEFORE the SYS1.MACLIB library.  SOP, put all
> >licensed product libraries ahead of base system libraries, right?
> >
> >Not in this case.  Turns out we have some old assembler ode that uses
> >the MVS IDENTIFY macro for reasonable business purposes, but now the
> >CICS MACLIB ALSO has a macro named IDENTIFY.
>
> --
> 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
> DTCC DISCLAIMER: This email and any files transmitted with it are
> confidential and intended solely for the use of the individual or entity to
> whom they are addressed. If you have received this email in error, please
> notify us immediately and delete the email and any attachments from your
> system. The recipient should check this email and any attachments for the
> presence of viruses. The company accepts no liability for any damage caused
> by any virus transmitted by this email. Message content created by DTCC is
> automatically secured using Transport Layer Security (TLS) encryption and
> will be encrypted and sent through a secure transmission connection if the
> recipient's system is configured to support TLS on the incoming email
> gateway. If there is no TLS configured or the encryption certificate is
> invalid on the recipient's system, the email communication will be sent
> through an unencrypted channel. Organizations communicating with DTCC
> should be using TLS v1.2 or newer to ensure continuation of encrypted
> communications. DTCC will not be responsible for any disclosure of private
> information or any related security incident resulting from an
> organization's inability to receive secure electronic communications
> through the current version of TLS.
>
> --
> For IBM-MAIN subscribe / signoff / archive access 

Re: Using DFSORT to display binary and Packed Decimal values

[Nigel Morton]

I thought I had a job that did exactly this but I can't find it. However,
there are plenty of examples indexed at
https://www.ibm.com/support/pages/dfsort-icetool-papers-and-examples
including for DCOLLECT.

On Wed, 20 Jul 2022 at 11:43, Jack Zukt  wrote:

> Hi,
>
> I am using DFSORT to process DCOLLECT Data Records. I am trying to format a
> output record with the dataset name, volser, allocated space, creation date
> and last ref date.
> On the DCOLLECT Data Record, the allocated space is on a binary format and
> the date fields are all on packed decimal. I would like those to be
> reformatted to a character format as I want it to be readable. So far I
> have been reading the manual and have been on a trial and error process,
> with a lot of tries and a lot of errors.  As this must be a simple thing to
> do, I must be doing it all wrong.
> Ant help will be greatly appreciated,
> Best regards,
> Jack
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS macro name IDENTIFY

[Ward Able, Grant]

As stated by IBM Hursley (John Tilling) on the CICS-List,  CICS does not ship 
an IDENTIFY macro!

Regards - Grant.
Telephone Internal: 201496 (London)

EAM - Enterprise Application Middleware

In theory, there's no difference between theory and practice. In practice, 
there is.

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

If you don't have time to do it right, when will you have the time to do it 
over? - John Wooden



DTCC Public (White)

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: 20 July 2022 14:18
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS macro 
name IDENTIFY

ATTENTION: External Email - Be Suspicious of Attachments, Links and Requests 
for Login Information.

IDENTIFY has existed and been documented since Old Man Noach got high on PCP. 
Yes, CICS should have known better.

The RFE wouldn't be for unique names; that ship has sailed. It would be for new 
syntax on COPY.

If your program needs both, you're screwed. Welcome to CM Hell.


--
Shmuel (Seymour J.) Metz
https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3data=05%7C01%7Cgwardable%40DTCC.COM%7C84a10466544949519ea508da6a5254cd%7C0465519d7f554d47998b55e2a86f04a8%7C0%7C0%7C637939199102819262%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=RmTDzrKLqfpMeWzgN3LzujQbqe9CNNgHDschdGnwYwY%3Dreserved=0


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, July 20, 2022 9:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS macro 
name IDENTIFY

On Wed, 20 Jul 2022 12:18:56 +, Seymour J Metz wrote:

>There is no COPY ddname(member) in HLASM. That sounds like an obvious 
>candidate for an RFE.
>
Hasn't the MVS macro name IDENTIFY existed long enough that CICS should have 
known better?

That's not an RFE; tt's a bug; BAD.  Suppose a program needs both services.


>-Original Message-
>From: Farley, Peter x23353
>Sent: Tuesday, July 19, 2022 2:07 PM
>
>Cross-posted to IBM-MAIN and CICS-L.
>
>We just encountered this.  Our SDLC mechanism has CICS.BASE.MACLIB (an 
>ALIAS for the current product version library) positioned in the 
>assembler translate step BEFORE the SYS1.MACLIB library.  SOP, put all 
>licensed product libraries ahead of base system libraries, right?
>
>Not in this case.  Turns out we have some old assembler ode that uses 
>the MVS IDENTIFY macro for reasonable business purposes, but now the 
>CICS MACLIB ALSO has a macro named IDENTIFY.

--
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
DTCC DISCLAIMER: This email and any files transmitted with it are confidential 
and intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this email in error, please notify us 
immediately and delete the email and any attachments from your system. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. Message content created by DTCC is automatically 
secured using Transport Layer Security (TLS) encryption and will be encrypted 
and sent through a secure transmission connection if the recipient's system is 
configured to support TLS on the incoming email gateway. If there is no TLS 
configured or the encryption certificate is invalid on the recipient's system, 
the email communication will be sent through an unencrypted channel. 
Organizations communicating with DTCC should be using TLS v1.2 or newer to 
ensure continuation of encrypted communications. DTCC will not be responsible 
for any disclosure of private information or any related security incident 
resulting from an organization's inability to receive secure electronic 
communications through the current version of TLS.

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

Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS macro name IDENTIFY

[Seymour J Metz]

IDENTIFY has existed and been documented since Old Man Noach got high on PCP. 
Yes, CICS should have known better.

The RFE wouldn't be for unique names; that ship has sailed. It would be for new 
syntax on COPY.

If your program needs both, you're screwed. Welcome to CM Hell.


--
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, July 20, 2022 9:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS macro 
name IDENTIFY

On Wed, 20 Jul 2022 12:18:56 +, Seymour J Metz wrote:

>There is no COPY ddname(member) in HLASM. That sounds like an obvious 
>candidate for an RFE.
>
Hasn't the MVS macro name IDENTIFY existed long enough that CICS should
have known better?

That's not an RFE; tt's a bug; BAD.  Suppose a program needs both services.


>-Original Message-
>From: Farley, Peter x23353
>Sent: Tuesday, July 19, 2022 2:07 PM
>
>Cross-posted to IBM-MAIN and CICS-L.
>
>We just encountered this.  Our SDLC mechanism has CICS.BASE.MACLIB (an ALIAS
>for the current product version library) positioned in the assembler
>translate step BEFORE the SYS1.MACLIB library.  SOP, put all licensed
>product libraries ahead of base system libraries, right?
>
>Not in this case.  Turns out we have some old assembler ode that uses the
>MVS IDENTIFY macro for reasonable business purposes, but now the CICS MACLIB
>ALSO has a macro named IDENTIFY.

--
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: Name conflict: CICS macro name IDENTIFY conflicts with MVS macro name IDENTIFY

[Paul Gilmartin]

On Wed, 20 Jul 2022 12:18:56 +, Seymour J Metz wrote:

>There is no COPY ddname(member) in HLASM. That sounds like an obvious 
>candidate for an RFE.
> 
Hasn't the MVS macro name IDENTIFY existed long enough that CICS should
have known better?

That's not an RFE; tt's a bug; BAD.  Suppose a program needs both services.


>-Original Message-
>From: Farley, Peter x23353
>Sent: Tuesday, July 19, 2022 2:07 PM
>
>Cross-posted to IBM-MAIN and CICS-L.
>
>We just encountered this.  Our SDLC mechanism has CICS.BASE.MACLIB (an ALIAS
>for the current product version library) positioned in the assembler
>translate step BEFORE the SYS1.MACLIB library.  SOP, put all licensed
>product libraries ahead of base system libraries, right?
>
>Not in this case.  Turns out we have some old assembler ode that uses the
>MVS IDENTIFY macro for reasonable business purposes, but now the CICS MACLIB
>ALSO has a macro named IDENTIFY.

-- 
gil

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

Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS macro name IDENTIFY

[Bertus Bekker]

Or maybe concatenate the MACRO you want to use in front of SYSIN
(could sometimes clash with directives that must be first)

On Wed, Jul 20, 2022 at 2:19 PM Seymour J Metz  wrote:

> There is no COPY ddname(member) in HLASM. That sounds like an obvious
> candidate for an RFE.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Charles Mills [charl...@mcn.org]
> Sent: Tuesday, July 19, 2022 5:31 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS
> macro name IDENTIFY
>
> In COBOL you can say COPY member OF ddname, so you can get an instance of
> 'member' that is not the first one in SYSLIB. PL/I has something similar.
>
> I don't think there is any way to do that in HLASM, is there? That would be
> nice.
>
> Perhaps a *PROCESS option to say "find macro IDENTIFY in the SYSMAC
> concatenation." (And then you would provide a SYSMAC DD statement pointing
> to SYS1.MACLIB or similar.) Or a hierarchical opcode name scheme like
> SYSMAC.IDENTIFY.
>
> Classic name collision problem. Many languages provide some way to control
> namespaces at the individual source code level.
>
> If IDENTIFY had been invented today they would have been called IEFIDENT
> and
> DFHIDENT, thereby solving the problem (but at a cost in memorability).
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Farley, Peter x23353
> Sent: Tuesday, July 19, 2022 2:07 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Name conflict: CICS macro name IDENTIFY conflicts with MVS macro
> name IDENTIFY
>
> Cross-posted to IBM-MAIN and CICS-L.
>
> We just encountered this.  Our SDLC mechanism has CICS.BASE.MACLIB (an
> ALIAS
> for the current product version library) positioned in the assembler
> translate step BEFORE the SYS1.MACLIB library.  SOP, put all licensed
> product libraries ahead of base system libraries, right?
>
> Not in this case.  Turns out we have some old assembler ode that uses the
> MVS IDENTIFY macro for reasonable business purposes, but now the CICS
> MACLIB
> ALSO has a macro named IDENTIFY.
>
> Now that assembler program cannot be maintained or changed until the SYSLIB
> setup in the SDLC mechanism is updated (never a short process).
>
> The obvious solution here is of course to change the SDLC setup to put the
> CICS MACLIB after SYS1.MACLIB, but was this documented to the sysprogs that
> there is a (new?) name conflict here?
>
> Do the CICS and MVS sysprogs even talk to each other or to the SDLC
> mechanism maintainers?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: 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: Name conflict: CICS macro name IDENTIFY conflicts with MVS macro name IDENTIFY

[Seymour J Metz]

There is no COPY ddname(member) in HLASM. That sounds like an obvious candidate 
for an RFE.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Tuesday, July 19, 2022 5:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS macro 
name IDENTIFY

In COBOL you can say COPY member OF ddname, so you can get an instance of
'member' that is not the first one in SYSLIB. PL/I has something similar.

I don't think there is any way to do that in HLASM, is there? That would be
nice.

Perhaps a *PROCESS option to say "find macro IDENTIFY in the SYSMAC
concatenation." (And then you would provide a SYSMAC DD statement pointing
to SYS1.MACLIB or similar.) Or a hierarchical opcode name scheme like
SYSMAC.IDENTIFY.

Classic name collision problem. Many languages provide some way to control
namespaces at the individual source code level.

If IDENTIFY had been invented today they would have been called IEFIDENT and
DFHIDENT, thereby solving the problem (but at a cost in memorability).

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Farley, Peter x23353
Sent: Tuesday, July 19, 2022 2:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Name conflict: CICS macro name IDENTIFY conflicts with MVS macro
name IDENTIFY

Cross-posted to IBM-MAIN and CICS-L.

We just encountered this.  Our SDLC mechanism has CICS.BASE.MACLIB (an ALIAS
for the current product version library) positioned in the assembler
translate step BEFORE the SYS1.MACLIB library.  SOP, put all licensed
product libraries ahead of base system libraries, right?

Not in this case.  Turns out we have some old assembler ode that uses the
MVS IDENTIFY macro for reasonable business purposes, but now the CICS MACLIB
ALSO has a macro named IDENTIFY.

Now that assembler program cannot be maintained or changed until the SYSLIB
setup in the SDLC mechanism is updated (never a short process).

The obvious solution here is of course to change the SDLC setup to put the
CICS MACLIB after SYS1.MACLIB, but was this documented to the sysprogs that
there is a (new?) name conflict here?

Do the CICS and MVS sysprogs even talk to each other or to the SDLC
mechanism maintainers?

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

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

Re: z/OS 1.4 submit

[Seymour J Metz]

I can't speak for others, but if the reference manual for the command doesn't 
explicitly show support for ddname or dsn then I won't use that syntax in 
production even if I've tested it and it works, although I would submit an RCF. 
But it's not my dog; do as you wish.


--
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: Tuesday, July 19, 2022 1:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 1.4 submit

On Tue, 19 Jul 2022 16:11:10 +, Seymour J Metz  wrote:

>If each operand either cannot be a Unix file or must be a Unix file then it 
>doesn't matter whether the command uses fopen() or open(). Only if the command 
>has an operand that can specify either a path or a ddname (or path or dsname) 
>is there an issue.
>
Where is it documented which commands other than the c89
family support a ddname?  Where is it documented which
commands support fopen()?

Would you just guess?  Would you design a production application
based on a guess?  Of course if you code your application in
XL C/C++ the support for fopen( "//DD: ..." ) is well documented.


>On Fri, 15 Jul 2022 10:05:53 +, Seymour J Metz  wrote:
>
>>Allocate an internal reader and copy the file to it. Ensure that the command 
>>you use supports fopen() syntax.

--
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: z/OS FTP ISPF Client - Available?

[Seymour J Metz]

It would be easy to write one of the tools available from, e.g., CBTTAPE, don't 
suit your needs.

Has anybody compiled a comprehensive list of what's available?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Jasi Grewal [040674ae00fc-dmarc-requ...@listserv.ua.edu]
Sent: Tuesday, July 19, 2022 4:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: z/OS FTP ISPF Client - Available?

Greetings,
I work in an organization where there is a numerous FTP requirements to 
transfer the Data between each z/OS Systems and they don't use NJE.
I was wondering if there is an FTP ISPF Tool and which can be used to transfer 
data between other z/OS Systems or other Operating Systems.
It would be interesting to determine if there is a Tool available and maybe I 
can find time to write one this year, if there is none.
Thank You in advance,Regards,Jasi Grewal.

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

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

Re: z/OS FTP ISPF Client - Available?

[Seymour J Metz]

FTP does not depend on NJE.

NJE is a protocol for exchanging jobs and other data among various IBM 
operating systems. For MVS both JES2 and JES3 with BDT support NJE.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob 
Bridges [robhbrid...@gmail.com]
Sent: Tuesday, July 19, 2022 4:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS FTP ISPF Client - Available?

What's wrong with MVS' native FTP?  Or does that depend on NJE (whatever that 
is)?

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

/* Science is a differential equation.  Religion is a boundary condition.  
-Alan Turing, quoted in J D Barrow's _Theories of Everything_ */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jasi Grewal
Sent: Tuesday, July 19, 2022 16:05

I work in an organization where there is a numerous FTP requirements to 
transfer the Data between each z/OS Systems and they don't use NJE.  I was 
wondering if there is an FTP ISPF Tool and which can be used to transfer data 
between other z/OS Systems or other Operating Systems.  It would be interesting 
to determine if there is a Tool available and maybe I can find time to write 
one this year, if there is none.

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

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

VSMLIST SP=PVT,SPACE=FREE question

[Joseph Reichman]

The following is a layout for VSMLIST SP=PVT,SPACE=FREE

It is my understanding that with SPACE=FREE the free space entry is listed
and then the allocated ?

So for the following entry 

 Starting with the subpool descriptor, then TCB then number of free blocks
then free block address and free block length, what follows is the number of
allocated block followed by allocated address followed by allocated length 

0008E508 008FD250  0001 7FF9C000 00051000 0001 7FF9C000 0E28

Would my understanding be correct that the allocated address is (7FF9C000 +
00051000) - E28 so the  starting address of  the allocated storage is
7FFEC1D8 ?  

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

Using DFSORT to display binary and Packed Decimal values

[Jack Zukt]

Hi,

I am using DFSORT to process DCOLLECT Data Records. I am trying to format a
output record with the dataset name, volser, allocated space, creation date
and last ref date.
On the DCOLLECT Data Record, the allocated space is on a binary format and
the date fields are all on packed decimal. I would like those to be
reformatted to a character format as I want it to be readable. So far I
have been reading the manual and have been on a trial and error process,
with a lot of tries and a lot of errors.  As this must be a simple thing to
do, I must be doing it all wrong.
Ant help will be greatly appreciated,
Best regards,
Jack

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

Re: DFSORT/ICETOOL

[Jack Zukt]

Hi,
Thank you for the suggestion but that only shifts the problem for the three
rightmost positions. And it is summarizing on those three positions, not on
the four as it should.
Regards
Jack

On Wed, 20 Jul 2022 at 09:28, Mike Schwab  wrote:

> > OVERLAY=(FMT-YEAR:71,04,   # YEAR
>
> Since you are getting the first three digits, I suspect you are
> getting a blank in front.  Try 72 instead of 71.
>
> On Wed, Jul 20, 2022 at 3:11 AM Jack Zukt  wrote:
> >
> > Hi Kolusu,
> >
> > Thank you very much for your help. It works almost as it should. There
> is a
> > small glitch and I can not understand why: the year, on the output, has
> > only the three leftmost positions:
> >
> > 199  DUMMYCG21588 KB 21 MB0 GB  0 TB
> > 199  DUMMYCH   260204 KB254 MB0 GB  0 TB
> > 199  FDUMMY  8041 KB  7 MB0 GB  0 TB
> >
> > Best Regards,
> > Jack
> >
> >
> > On Tue, 19 Jul 2022 at 16:39, Sri h Kolusu  wrote:
> >
> > > >> I would like to add all the space for each year and for each High
> Level
> > > Qualifier. Is there a way to do this using DFSORT or ICETOOL
> > >
> > > Jack,
> > >
> > > It is quite simple and can be done.  Since you haven't specified the
> > > positions of the data, I assumed the following.
> > >
> > > 1. The input file has LRECL=133 RECFM=FBA
> > > 2. Position 2 thru 10 the space value
> > > 3. Position 11 has the space unit ( K = KB , M=MB G=GB)
> > > 4. The dataset name starts in position 13 which has the HLQ
> > > 5. The year value starts in position 71 thru 74
> > >
> > > //STEP0100 EXEC PGM=SORT
> > > //SYSOUT   DD SYSOUT=*
> > > //SYMNOUT  DD SYSOUT=*
> > > //SYMNAMES DD *
> > > INP-BYTE,02,08,UFF
> > > FMT-YEAR,134,04,UFF
> > > SKIP,1
> > > FMT-HLQ,*,08,CH
> > > SKIP,1
> > > FMT-UNT,*,10,UFF
> > > SKIP,1
> > > FMT-BYT,*,08,PD
> > > //SORTIN   DD DISP=SHR,DSN=Your.input.FBA.rmm.report
> > > //SORTOUT  DD SYSOUT=*
> > > //SYSINDD *
> > >   INREC PARSE=(%01=(ABSPOS=13,ENDBEFR=C'.',FIXLEN=8)),
> > > OVERLAY=(FMT-YEAR:71,04,   # YEAR
> > >  FMT-HLQ:%01,
> > >  FMT-UNT:11,1,CHANGE=(10,C'K',C'001024',
> > >  C'M',C'0001048576',
> > >  C'G',C'1073741824'),
> > >  NOMATCH=(C'01'),
> > >  FMT-BYT:INP-BYTE,MUL,
> > >  FMT-UNT,TO=PD,LENGTH=8)
> > >
> > >   SORT FIELDS=(FMT-YEAR,A,
> > >FMT-HLQ,A)
> > >
> > >SUM FIELDS=(FMT-BYT)
> > >
> > >   OUTREC BUILD=(FMT-YEAR,
> > > X,
> > > FMT-HLQ,
> > > X,
> > > FMT-BYT,M10,LENGTH=12,
> > > X,
> > > FMT-BYT,DIV,+001024,M10,LENGTH=10,C' KB',
> > > X,
> > > FMT-BYT,DIV,+0001048576,M10,LENGTH=08,C' MB',
> > > X,
> > > FMT-BYT,DIV,+1073741824,M10,LENGTH=06,C' GB')
> > > /*
> > >
> > > The output will be shown as
> > >
> > > Year , HLQ, Byte-total , Byte-total-in-KB, Byte-total-in-MB,
> > > Byte-total-in-GB  ( You can pick and choose which ever unit you want)
> . The
> > > KB,MB,GB values are in all integers , if you want the decimals also,
> then
> > > it is easy to incorporate. Let me know if you are interested in that.
> > >
> > >
> > > PS: It would have been nice if you used a descriptive  topic title
> rather
> > > than the PGM name for the topic.  Something like "Summing up values
> from a
> > > RMM report using DFSORT"
> > >
> > > Thanks,
> > > Kolusu
> > > DFSORT Development
> > > IBM Corporation
> > >
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: DFSORT/ICETOOL

[Mike Schwab]

> OVERLAY=(FMT-YEAR:71,04,   # YEAR

Since you are getting the first three digits, I suspect you are
getting a blank in front.  Try 72 instead of 71.

On Wed, Jul 20, 2022 at 3:11 AM Jack Zukt  wrote:
>
> Hi Kolusu,
>
> Thank you very much for your help. It works almost as it should. There is a
> small glitch and I can not understand why: the year, on the output, has
> only the three leftmost positions:
>
> 199  DUMMYCG21588 KB 21 MB0 GB  0 TB
> 199  DUMMYCH   260204 KB254 MB0 GB  0 TB
> 199  FDUMMY  8041 KB  7 MB0 GB  0 TB
>
> Best Regards,
> Jack
>
>
> On Tue, 19 Jul 2022 at 16:39, Sri h Kolusu  wrote:
>
> > >> I would like to add all the space for each year and for each High Level
> > Qualifier. Is there a way to do this using DFSORT or ICETOOL
> >
> > Jack,
> >
> > It is quite simple and can be done.  Since you haven't specified the
> > positions of the data, I assumed the following.
> >
> > 1. The input file has LRECL=133 RECFM=FBA
> > 2. Position 2 thru 10 the space value
> > 3. Position 11 has the space unit ( K = KB , M=MB G=GB)
> > 4. The dataset name starts in position 13 which has the HLQ
> > 5. The year value starts in position 71 thru 74
> >
> > //STEP0100 EXEC PGM=SORT
> > //SYSOUT   DD SYSOUT=*
> > //SYMNOUT  DD SYSOUT=*
> > //SYMNAMES DD *
> > INP-BYTE,02,08,UFF
> > FMT-YEAR,134,04,UFF
> > SKIP,1
> > FMT-HLQ,*,08,CH
> > SKIP,1
> > FMT-UNT,*,10,UFF
> > SKIP,1
> > FMT-BYT,*,08,PD
> > //SORTIN   DD DISP=SHR,DSN=Your.input.FBA.rmm.report
> > //SORTOUT  DD SYSOUT=*
> > //SYSINDD *
> >   INREC PARSE=(%01=(ABSPOS=13,ENDBEFR=C'.',FIXLEN=8)),
> > OVERLAY=(FMT-YEAR:71,04,   # YEAR
> >  FMT-HLQ:%01,
> >  FMT-UNT:11,1,CHANGE=(10,C'K',C'001024',
> >  C'M',C'0001048576',
> >  C'G',C'1073741824'),
> >  NOMATCH=(C'01'),
> >  FMT-BYT:INP-BYTE,MUL,
> >  FMT-UNT,TO=PD,LENGTH=8)
> >
> >   SORT FIELDS=(FMT-YEAR,A,
> >FMT-HLQ,A)
> >
> >SUM FIELDS=(FMT-BYT)
> >
> >   OUTREC BUILD=(FMT-YEAR,
> > X,
> > FMT-HLQ,
> > X,
> > FMT-BYT,M10,LENGTH=12,
> > X,
> > FMT-BYT,DIV,+001024,M10,LENGTH=10,C' KB',
> > X,
> > FMT-BYT,DIV,+0001048576,M10,LENGTH=08,C' MB',
> > X,
> > FMT-BYT,DIV,+1073741824,M10,LENGTH=06,C' GB')
> > /*
> >
> > The output will be shown as
> >
> > Year , HLQ, Byte-total , Byte-total-in-KB, Byte-total-in-MB,
> > Byte-total-in-GB  ( You can pick and choose which ever unit you want) . The
> > KB,MB,GB values are in all integers , if you want the decimals also, then
> > it is easy to incorporate. Let me know if you are interested in that.
> >
> >
> > PS: It would have been nice if you used a descriptive  topic title rather
> > than the PGM name for the topic.  Something like "Summing up values from a
> > RMM report using DFSORT"
> >
> > Thanks,
> > Kolusu
> > DFSORT Development
> > IBM Corporation
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Re: DFSORT/ICETOOL

[Jack Zukt]

Hi Kolusu,

Thank you very much for your help. It works almost as it should. There is a
small glitch and I can not understand why: the year, on the output, has
only the three leftmost positions:

199  DUMMYCG21588 KB 21 MB0 GB  0 TB
199  DUMMYCH   260204 KB254 MB0 GB  0 TB
199  FDUMMY  8041 KB  7 MB0 GB  0 TB

Best Regards,
Jack


On Tue, 19 Jul 2022 at 16:39, Sri h Kolusu  wrote:

> >> I would like to add all the space for each year and for each High Level
> Qualifier. Is there a way to do this using DFSORT or ICETOOL
>
> Jack,
>
> It is quite simple and can be done.  Since you haven't specified the
> positions of the data, I assumed the following.
>
> 1. The input file has LRECL=133 RECFM=FBA
> 2. Position 2 thru 10 the space value
> 3. Position 11 has the space unit ( K = KB , M=MB G=GB)
> 4. The dataset name starts in position 13 which has the HLQ
> 5. The year value starts in position 71 thru 74
>
> //STEP0100 EXEC PGM=SORT
> //SYSOUT   DD SYSOUT=*
> //SYMNOUT  DD SYSOUT=*
> //SYMNAMES DD *
> INP-BYTE,02,08,UFF
> FMT-YEAR,134,04,UFF
> SKIP,1
> FMT-HLQ,*,08,CH
> SKIP,1
> FMT-UNT,*,10,UFF
> SKIP,1
> FMT-BYT,*,08,PD
> //SORTIN   DD DISP=SHR,DSN=Your.input.FBA.rmm.report
> //SORTOUT  DD SYSOUT=*
> //SYSINDD *
>   INREC PARSE=(%01=(ABSPOS=13,ENDBEFR=C'.',FIXLEN=8)),
> OVERLAY=(FMT-YEAR:71,04,   # YEAR
>  FMT-HLQ:%01,
>  FMT-UNT:11,1,CHANGE=(10,C'K',C'001024',
>  C'M',C'0001048576',
>  C'G',C'1073741824'),
>  NOMATCH=(C'01'),
>  FMT-BYT:INP-BYTE,MUL,
>  FMT-UNT,TO=PD,LENGTH=8)
>
>   SORT FIELDS=(FMT-YEAR,A,
>FMT-HLQ,A)
>
>SUM FIELDS=(FMT-BYT)
>
>   OUTREC BUILD=(FMT-YEAR,
> X,
> FMT-HLQ,
> X,
> FMT-BYT,M10,LENGTH=12,
> X,
> FMT-BYT,DIV,+001024,M10,LENGTH=10,C' KB',
> X,
> FMT-BYT,DIV,+0001048576,M10,LENGTH=08,C' MB',
> X,
> FMT-BYT,DIV,+1073741824,M10,LENGTH=06,C' GB')
> /*
>
> The output will be shown as
>
> Year , HLQ, Byte-total , Byte-total-in-KB, Byte-total-in-MB,
> Byte-total-in-GB  ( You can pick and choose which ever unit you want) . The
> KB,MB,GB values are in all integers , if you want the decimals also, then
> it is easy to incorporate. Let me know if you are interested in that.
>
>
> PS: It would have been nice if you used a descriptive  topic title rather
> than the PGM name for the topic.  Something like "Summing up values from a
> RMM report using DFSORT"
>
> Thanks,
> Kolusu
> DFSORT Development
> IBM Corporation
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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