Re: Convert a Metal C control block mapping to Assembler DSECT ?

2020-02-14 Thread Paul Gilmartin
On Fri, 14 Feb 2020 12:26:44 -0800, Charles Mills wrote:

>I suspect they would not take an APAR 
>
"Toleration is the mother of mediocrity."  (source unknown)

>I suspect they would cite compatibility concerns if they changed it. 
>
That's because they didn't do it right the first time.  And programmers
tolerated it.

>Yeah, yeah, I know, could be controlled by an option. I don't think EDCDSECT 
>is IBM's highest priority.
>
Adding options increases testing requirements exponentially.

>Yes, many control blocks are bilingual. So what? (Not trying to be rude; just 
>mean ... so what?) PL/X is in any event a better starting point for C than is 
>HLASM. Or am I missing your point?
>
Somewhat missing.  I was thinking of those control blocks that are
currently delivered with PL/X appended.  IIRC, Peter(?) has said that
the HLASM is extracted automatically from the PL/X.

>... DS CL8 is a perfectly fine way of defining a 64-bit integer in HLASM, 
>
DS 0D,FL8 is finer.  I was dismayed not to find an "FG" type for that.

>... but also a common way of course of defining a DD name or member name 
>field. 
>
Exactly the hazard I envisioned.

>I personally solved the problem by coding some small distinctive comment token 
>-- something like $@$ or something like that -- on every 64-bit integer or 
>address so that they were easy to find (and then fix) in the converted struct. 
> 
>
Portability when every programmer adopts a different convention.

-- gil

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


Re: SMPE BYPASS(HOLDSYS,HOLDERR)

2020-02-14 Thread CM Poncelet
Yes I have run APPLY with BYPASS(HOLDERR), but only when the "HOLD(s)"
would not have impacted the system.
 
Just to be safe, do the following:
(a) Backup your *whole* SMP/E environment (CSI, GLOBAL, TLIB and DLIB
zones, and all their associated SMP/E datasets) to a GDG (+1) entry,
using PGM=ADRDSSU. (You should be able to do this for all your product's
SMP/E datasets and associated datasets by specifying their DSN hlq +
wild card ".**".)
(b) Now run your SMP/E APPLY with BYPASS(HOLDERR,HOLDSYS) on a 'sandbox'
test LPAR. Then use your updated SMP/E loadlib etc. datasets to verify
*fully* that the APPLY introduced no errors.
(c) If any errors are detected, restore your *whole* SMP/E environment
from the GDG entry's (now 0) PGM=ADRDSSU backup.
(d) Else, consider it safe to implement the APPLY
BYPASS(HOLDERR,HOLDSYS) on a production LPAR.
 
BTW "APPLY" can be undone ("REDO" and "REJECT", if memory serves) but
"ACCEPT" cannot. So do not ACCEPT the APPLY, even if all seems to be
working OK after the APPLY.
 
HTH.
 
Cheers, Chris Poncelet (retired sysprog)
 

On 14/02/2020 20:22, Paul Jodlowski wrote:
> Has anybody ever ran SMPE apply with bypass(holderr)?
> I need to install PTF UA92779 (this is needed to install DB2 v12)
> And the only way to get this PTF installed is with bypass(holderr).
> >From the BYPASSED HOLD REASON REPORT FOR APPLY CHECK PROCESSING
> ++ HOLD(UA92779) SYS FMID(HDZ2220) REASON(DELETE) DATE(17216)   
>COMMENT  
> (++DELETE Load module IGG0193V is being deleted and rebuilt in  
>  order to include an ICSF module to support the DFSMS Data Set  
>  Encryption function. SMP/E cannot RESTORE this PTF because it  
>  contains a ++DELETE statement for IGG0193V.  Over 20 PTFs are  
>  required to enable this function and are co-REQ'ed to ensure   
>  all are installed together.  Due to the significant changes
>  introduced by this function, and the need for the ++DELETE 
>  which prevents SMP/E RESTORE, best practices suggest it is 
>  prudent to create a back-up of your system prior to installing 
>  these PTFs.).  
> ++ HOLD(UA92836) SYS FMID(HDZ2220) REASON(DELETE) DATE(17205)
>COMMENT   
>(++DELETE Load module IDAV194A is being deleted and rebuilt in   
>order to include an ICSF module to support the DFSMS Data Set   
>Encryption function. SMP/E cannot RESTORE this PTF because it   
>contains a ++DELETE statement for IDAV194A. Over 20 PTFs are
>required to enable this function and are co-REQ'ed to ensure all
>are installed together. Due to the significant changes  
>introduced by this function, and the need for the ++DELETE  
>which prevents SMP/E RESTORE, best practices suggest it is  
>prudent to create a back-up of your system prior to installing  
>these PTFs.).   
>
> Cheers
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: 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: SMPE BYPASS(HOLDSYS,HOLDERR)

2020-02-14 Thread Mark Jacobs
Yes, but that's not what OP was asking. Based on the information provided, I'm 
not seeing any need to bypass HOLDERROR on the apply. Some other PTFs in the 
apply stream might have unresolved PE's however. If so, the OP will have to 
decide whether the PE will have an impact on their environment before they can 
safely bypass the HOLDERROR.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Friday, February 14, 2020 6:06 PM, Mike Schwab  
wrote:

> Since it will be doing a delete, SMPE cannot restore the PTF. So you
> need to back up the SMPE files and target files in order to do a
> restore. Then you can bypass the hold and apply the PTFs.
>
> On Fri, Feb 14, 2020 at 2:22 PM Paul Jodlowski
> pgjodlow...@nationalindemnity.com wrote:
>
> > Has anybody ever ran SMPE apply with bypass(holderr)?
> > I need to install PTF UA92779 (this is needed to install DB2 v12)
> > And the only way to get this PTF installed is with bypass(holderr).
> > From the BYPASSED HOLD REASON REPORT FOR APPLY CHECK PROCESSING
> > ++ HOLD(UA92779) SYS FMID(HDZ2220) REASON(DELETE) DATE(17216)
> > COMMENT
> > (++DELETE Load module IGG0193V is being deleted and rebuilt in
> > order to include an ICSF module to support the DFSMS Data Set
> > Encryption function. SMP/E cannot RESTORE this PTF because it
> > contains a ++DELETE statement for IGG0193V. Over 20 PTFs are
> > required to enable this function and are co-REQ'ed to ensure
> > all are installed together. Due to the significant changes
> > introduced by this function, and the need for the ++DELETE
> > which prevents SMP/E RESTORE, best practices suggest it is
> > prudent to create a back-up of your system prior to installing
> > these PTFs.).
> > ++ HOLD(UA92836) SYS FMID(HDZ2220) REASON(DELETE) DATE(17205)
> > COMMENT
> > (++DELETE Load module IDAV194A is being deleted and rebuilt in
> > order to include an ICSF module to support the DFSMS Data Set
> > Encryption function. SMP/E cannot RESTORE this PTF because it
> > contains a ++DELETE statement for IDAV194A. Over 20 PTFs are
> > required to enable this function and are co-REQ'ed to ensure all
> > are installed together. Due to the significant changes
> > introduced by this function, and the need for the ++DELETE
> > which prevents SMP/E RESTORE, best practices suggest it is
> > prudent to create a back-up of your system prior to installing
> > these PTFs.).
> > Cheers
> >
> > 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


Seeking help with TWSz install

2020-02-14 Thread Scott R. McFall
Looking for someone with recent experience with TWSz install & configuration.   
Part-time, remote consulting opportunity.

If interested, please contact me at 
smcf...@proechconsulting.com or 
800-373-9188x113.


SCOTT REDMOND MCFALL

VP, BUSINESS DEVELOPMENT & STRATEGY  |  PROTECH ENTERPRISE IT TRAINING & 
CONSULTING



T:  800.373.9188 ext. 113

M:  412.445.8070

E:  smcf...@protechtraining.com

W:  protechtraining.com


My LinkedIn Profile

Legal Notice  Privacy 
Policy






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


Re: Convert a Metal C control block mapping to Assembler DSECT ?

2020-02-14 Thread Charles Mills
> Aren't some z/OS control blocks distributed bilingual, HLASM and PL/X?

Did you mean "so might the utility use or have used HLASM input rather than 
PL/X?"

I suppose it might have, but Mr. Relson did not write it that way, and HLASM is 
inferior to PL/X for this purpose because it is less strongly typed or perhaps 
its types do not match up to C as well as PL/X's do. I think the use of PL/X 
for input is one of the reasons that the Relson utility (I never heard a 
program name) produces C structs that are much superior to those from EDCDSECT.

> Agree with Lionel's recommendation.

That should have been "agree with Gord's recommendation."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Friday, February 14, 2020 12:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Convert a Metal C control block mapping to Assembler DSECT ?

I suspect they would not take an APAR (although of course it turns out I do not 
actually speak for IBM). I suspect they would cite compatibility concerns if 
they changed it. Yeah, yeah, I know, could be controlled by an option. I don't 
think EDCDSECT is IBM's highest priority.

Yes, many control blocks are bilingual. So what? (Not trying to be rude; just 
mean ... so what?) PL/X is in any event a better starting point for C than is 
HLASM. Or am I missing your point?

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


Re: SMPE BYPASS(HOLDSYS,HOLDERR)

2020-02-14 Thread Mike Schwab
Since it will be doing a delete, SMPE cannot restore the PTF.  So you
need to back up the SMPE files and target files in order to do a
restore.  Then you can bypass the hold and apply the PTFs.

On Fri, Feb 14, 2020 at 2:22 PM Paul Jodlowski
 wrote:
>
> Has anybody ever ran SMPE apply with bypass(holderr)?
> I need to install PTF UA92779 (this is needed to install DB2 v12)
> And the only way to get this PTF installed is with bypass(holderr).
> From the BYPASSED HOLD REASON REPORT FOR APPLY CHECK PROCESSING
> ++ HOLD(UA92779) SYS FMID(HDZ2220) REASON(DELETE) DATE(17216)
>COMMENT
> (++DELETE Load module IGG0193V is being deleted and rebuilt in
>  order to include an ICSF module to support the DFSMS Data Set
>  Encryption function. SMP/E cannot RESTORE this PTF because it
>  contains a ++DELETE statement for IGG0193V.  Over 20 PTFs are
>  required to enable this function and are co-REQ'ed to ensure
>  all are installed together.  Due to the significant changes
>  introduced by this function, and the need for the ++DELETE
>  which prevents SMP/E RESTORE, best practices suggest it is
>  prudent to create a back-up of your system prior to installing
>  these PTFs.).
> ++ HOLD(UA92836) SYS FMID(HDZ2220) REASON(DELETE) DATE(17205)
>COMMENT
>(++DELETE Load module IDAV194A is being deleted and rebuilt in
>order to include an ICSF module to support the DFSMS Data Set
>Encryption function. SMP/E cannot RESTORE this PTF because it
>contains a ++DELETE statement for IDAV194A. Over 20 PTFs are
>required to enable this function and are co-REQ'ed to ensure all
>are installed together. Due to the significant changes
>introduced by this function, and the need for the ++DELETE
>which prevents SMP/E RESTORE, best practices suggest it is
>prudent to create a back-up of your system prior to installing
>these PTFs.).
>
> Cheers
>
> --
> 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: SMPE BYPASS(HOLDSYS,HOLDERR)

2020-02-14 Thread Mark Jacobs
Those are both bypassed with HOLDSYSTEM. That PTF isn't marked as PE in IBMLINK.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=getsearch=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Friday, February 14, 2020 3:22 PM, Paul Jodlowski 
 wrote:

 Has anybody ever ran SMPE apply with bypass(holderr)?
 I need to install PTF UA92779 (this is needed to install DB2 v12)
 And the only way to get this PTF installed is with bypass(holderr).
 From the BYPASSED HOLD REASON REPORT FOR APPLY CHECK PROCESSING
 ++ HOLD(UA92779) SYS FMID(HDZ2220) REASON(DELETE) DATE(17216)
 COMMENT
 (++DELETE Load module IGG0193V is being deleted and rebuilt in
 order to include an ICSF module to support the DFSMS Data Set
 Encryption function. SMP/E cannot RESTORE this PTF because it
 contains a ++DELETE statement for IGG0193V. Over 20 PTFs are
 required to enable this function and are co-REQ'ed to ensure
 all are installed together. Due to the significant changes
 introduced by this function, and the need for the ++DELETE
 which prevents SMP/E RESTORE, best practices suggest it is
 prudent to create a back-up of your system prior to installing
 these PTFs.).
 ++ HOLD(UA92836) SYS FMID(HDZ2220) REASON(DELETE) DATE(17205)
 COMMENT
 (++DELETE Load module IDAV194A is being deleted and rebuilt in
 order to include an ICSF module to support the DFSMS Data Set
 Encryption function. SMP/E cannot RESTORE this PTF because it
 contains a ++DELETE statement for IDAV194A. Over 20 PTFs are
 required to enable this function and are co-REQ'ed to ensure all
 are installed together. Due to the significant changes
 introduced by this function, and the need for the ++DELETE
 which prevents SMP/E RESTORE, best practices suggest it is
 prudent to create a back-up of your system prior to installing
 these PTFs.).

 Cheers

 
--

 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: 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: Convert a Metal C control block mapping to Assembler DSECT ?

2020-02-14 Thread Charles Mills
I suspect they would not take an APAR (although of course it turns out I do not 
actually speak for IBM). I suspect they would cite compatibility concerns if 
they changed it. Yeah, yeah, I know, could be controlled by an option. I don't 
think EDCDSECT is IBM's highest priority.

Yes, many control blocks are bilingual. So what? (Not trying to be rude; just 
mean ... so what?) PL/X is in any event a better starting point for C than is 
HLASM. Or am I missing your point?

I don't recall how the regex works. Perhaps it is semi-manual field by field. 
Yeah, the problem with HLASM is lack of strong typing. DS CL8 is a perfectly 
fine way of defining a 64-bit integer in HLASM, but also a common way of course 
of defining a DD name or member name field. I personally solved the problem by 
coding some small distinctive comment token -- something like $@$ or something 
like that -- on every 64-bit integer or address so that they were easy to find 
(and then fix) in the converted struct.  

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, February 14, 2020 11:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Convert a Metal C control block mapping to Assembler DSECT ?

On Fri, 14 Feb 2020 10:52:07 -0800, Charles Mills wrote:

>I would assume that Gord is using the EDCDSECT program which is legally part 
>of the XLC compiler. It assembles the DSECT -- can be either by itself or part 
>of some larger assembly -- and massages SYSADATA to produce a C-legal struct.
>
>... Its worst flaw IMHO is to make FOO DS FL8 and similar into char foo[8] . 
>
That deserves an APAR.  FL8 is not CL8.

>Our local hero Peter Relson developed an internal tool that does a much better 
>job, and z/OS is now shipping C struct header files for many, many MVS control 
>blocks. (The tool is not suitable for release because it uses PL/X input, 
>which is much better because it is closer to C than HLASM is. PL/X is more 
>strongly typed than HLASM.)
>
Aren't some z/OS control blocks distributed bilingual, HLASM and PL/X?

>Agree with Lionel's recommendation. Even if the usage is going to be 90% C and 
>10% HLASM you want to do the DSECT first and work from there.
>
>This has been discussed here previously, including someone who posted regex 
>that will automate the conversion of char foo[8] to long long foo;
>
But what if the original was FOO DS CL8, a common cliche in z/OS?

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


SMPE BYPASS(HOLDSYS,HOLDERR)

2020-02-14 Thread Paul Jodlowski
Has anybody ever ran SMPE apply with bypass(holderr)?
I need to install PTF UA92779 (this is needed to install DB2 v12)
And the only way to get this PTF installed is with bypass(holderr).
From the BYPASSED HOLD REASON REPORT FOR APPLY CHECK PROCESSING
++ HOLD(UA92779) SYS FMID(HDZ2220) REASON(DELETE) DATE(17216)   
   COMMENT  
(++DELETE Load module IGG0193V is being deleted and rebuilt in  
 order to include an ICSF module to support the DFSMS Data Set  
 Encryption function. SMP/E cannot RESTORE this PTF because it  
 contains a ++DELETE statement for IGG0193V.  Over 20 PTFs are  
 required to enable this function and are co-REQ'ed to ensure   
 all are installed together.  Due to the significant changes
 introduced by this function, and the need for the ++DELETE 
 which prevents SMP/E RESTORE, best practices suggest it is 
 prudent to create a back-up of your system prior to installing 
 these PTFs.).  
++ HOLD(UA92836) SYS FMID(HDZ2220) REASON(DELETE) DATE(17205)
   COMMENT   
   (++DELETE Load module IDAV194A is being deleted and rebuilt in   
   order to include an ICSF module to support the DFSMS Data Set   
   Encryption function. SMP/E cannot RESTORE this PTF because it   
   contains a ++DELETE statement for IDAV194A. Over 20 PTFs are
   required to enable this function and are co-REQ'ed to ensure all
   are installed together. Due to the significant changes  
   introduced by this function, and the need for the ++DELETE  
   which prevents SMP/E RESTORE, best practices suggest it is  
   prudent to create a back-up of your system prior to installing  
   these PTFs.). 
 
Cheers

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


Re: Convert a Metal C control block mapping to Assembler DSECT ?

2020-02-14 Thread Paul Gilmartin
On Fri, 14 Feb 2020 10:52:07 -0800, Charles Mills wrote:

>I would assume that Gord is using the EDCDSECT program which is legally part 
>of the XLC compiler. It assembles the DSECT -- can be either by itself or part 
>of some larger assembly -- and massages SYSADATA to produce a C-legal struct.
>
>... Its worst flaw IMHO is to make FOO DS FL8 and similar into char foo[8] . 
>
That deserves an APAR.  FL8 is not CL8.

>Our local hero Peter Relson developed an internal tool that does a much better 
>job, and z/OS is now shipping C struct header files for many, many MVS control 
>blocks. (The tool is not suitable for release because it uses PL/X input, 
>which is much better because it is closer to C than HLASM is. PL/X is more 
>strongly typed than HLASM.)
>
Aren't some z/OS control blocks distributed bilingual, HLASM and PL/X?

>Agree with Lionel's recommendation. Even if the usage is going to be 90% C and 
>10% HLASM you want to do the DSECT first and work from there.
>
>This has been discussed here previously, including someone who posted regex 
>that will automate the conversion of char foo[8] to long long foo;
>
But what if the original was FOO DS CL8, a common cliche in z/OS?

-- gil

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


Re: Convert a Metal C control block mapping to Assembler DSECT ?

2020-02-14 Thread Charles Mills
I would assume that Gord is using the EDCDSECT program which is legally part of 
the XLC compiler. It assembles the DSECT -- can be either by itself or part of 
some larger assembly -- and massages SYSADATA to produce a C-legal struct.

The result -- particularly for older IBM DSECTs -- is often spectacularly 
awfully unreadable, but nonetheless is syntactically and "layout-wise" correct. 
For simple DSECTs it does a very adequate job. I have used it on perhaps 100 
DSECTs and in that time have perhaps seen twice where the layout was truly 
wrong. Its worst flaw IMHO is to make FOO DS FL8 and similar into char foo[8] 
which is right layout-wise but wrong logically. At least you get a compile-time 
error if you say foo = 3; and can respond by editing the struct. The moral of 
the story is that if it is your own DSECT you probably want to try to get it 
right the first time so you don't have to keep re-editing the EDCDSECT output. 

Comments are preserved, kinda sorta.

Our local hero Peter Relson developed an internal tool that does a much better 
job, and z/OS is now shipping C struct header files for many, many MVS control 
blocks. (The tool is not suitable for release because it uses PL/X input, which 
is much better because it is closer to C than HLASM is. PL/X is more strongly 
typed than HLASM.)

Agree with Lionel's recommendation. Even if the usage is going to be 90% C and 
10% HLASM you want to do the DSECT first and work from there.

This has been discussed here previously, including someone who posted regex 
that will automate the conversion of char foo[8] to long long foo;

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, February 14, 2020 10:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Convert a Metal C control block mapping to Assembler DSECT ?

On Fri, 14 Feb 2020 10:31:02 -0500, Gord Tomlin wrote:

>On 2020-02-14 10:17, Lionel B Dyck wrote:
>> Is this possible, and more importantly, has anyone done it and be willing to
>> share?
>
>If the control block is one of your own creation, I'd recommend that you
>make the DSECT the original form, and then create the header file from
>the DSECT. It's much easier!
> 
Have you any tips and techniques.  For example, I suspect ORG becomes
struct and/or union.  How can one generate the terminating "}" in the
right place?

Is asmadata of assistance for this?  MACROs to assist?  Should the
original be preserved as embedded comments?

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


Re: Convert a Metal C control block mapping to Assembler DSECT ?

2020-02-14 Thread Paul Gilmartin
On Fri, 14 Feb 2020 10:31:02 -0500, Gord Tomlin wrote:

>On 2020-02-14 10:17, Lionel B Dyck wrote:
>> Is this possible, and more importantly, has anyone done it and be willing to
>> share?
>
>If the control block is one of your own creation, I'd recommend that you
>make the DSECT the original form, and then create the header file from
>the DSECT. It's much easier!
> 
Have you any tips and techniques.  For example, I suspect ORG becomes
struct and/or union.  How can one generate the terminating "}" in the
right place?

Is asmadata of assistance for this?  MACROs to assist?  Should the
original be preserved as embedded comments?

-- gil

>--
>
>Regards, Gord Tomlin
>Action Software International
>(a division of Mazda Computer Corporation)
>Tel: (905) 470-7113, Fax: (905) 470-6507
>Support: https://actionsoftware.com/support/
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: 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: Tape dataset tracking

2020-02-14 Thread Mike Schwab
The scratch would have uncataloged the tape.  Need to recatalog.

On Fri, Feb 14, 2020 at 10:37 AM Max Smith  wrote:
>
> Peter,
>
> Is the data set listed the data set you are looking for?  Is this a real tape 
> or virtual?  Is the volume listed as scratch?  or Private?  TS7700 or other?
>
> Max
>
> --
> 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: Tape dataset tracking

2020-02-14 Thread Max Smith
Peter,

After doing some additional checking, RMM does work as I thought.  RMM leaves 
the data set record around even if the data set expired.  RMM only deletes the 
data set record if the volume is picked up as a scratch volume and reused.  
That would mean the data set you are looking for has been overwritten and 
inaccessible.

Max

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


Re: Good reference for V=R

2020-02-14 Thread Michaela Weber
http://idcp.marist.edu/enterprisesystemseducation/ztidbitz.html#StorageManagement

z/OS Virtual Storage Map and Content Overview - Posted  01/17/2011

is #29 zNibbler (An Address Space Virtual Storage Layout)
which has a discussion and mapping for V=V and V=R.

There is also an option for V=R Terminology which is 
#19 zNibbler V=R terminology in the ztidbitz link but I can't get it to display 
contents using IE or Chrome.

Michaela Weber

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Friday, February 07, 2020 12:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Good reference for V=R


[EXTERNAL EMAIL] 

The wiki article on virtual storage has a reference to z/OS Concepts as a 
citation for, e.g., V=R.  The Knowledge Center page seems to have been renamed 
and I can't find that material there any more. I'm hesitant to give the 
initialization and tuna guide as a reference for a general article.  Can 
someone suggest something that spells out V=V, V=R and V=F for an audience not 
familiar with MVS? Thanks.


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

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: 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: Convert a Metal C control block mapping to Assembler DSECT ?

2020-02-14 Thread Joseph Reichman
The _asm makes it easy to copy assembler control blocks 

I have common code that I run on Windows and z/os 

When I want to update the assembler I use =m to copy the C variable to 
assembler 





> On Feb 14, 2020, at 10:31 AM, Gord Tomlin  
> wrote:
> 
> On 2020-02-14 10:17, Lionel B Dyck wrote:
>> Is this possible, and more importantly, has anyone done it and be willing to
>> share?
> 
> If the control block is one of your own creation, I'd recommend that you make 
> the DSECT the original form, and then create the header file from the DSECT. 
> It's much easier!
> 
> --
> 
> Regards, Gord Tomlin
> Action Software International
> (a division of Mazda Computer Corporation)
> Tel: (905) 470-7113, Fax: (905) 470-6507
> Support: https://actionsoftware.com/support/
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: 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: Tape dataset tracking

2020-02-14 Thread Max Smith
Peter,

Is the data set listed the data set you are looking for?  Is this a real tape 
or virtual?  Is the volume listed as scratch?  or Private?  TS7700 or other?

Max

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


Re: Convert a Metal C control block mapping to Assembler DSECT ?

2020-02-14 Thread Gord Tomlin

On 2020-02-14 10:17, Lionel B Dyck wrote:

Is this possible, and more importantly, has anyone done it and be willing to
share?


If the control block is one of your own creation, I'd recommend that you 
make the DSECT the original form, and then create the header file from 
the DSECT. It's much easier!


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

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


Convert a Metal C control block mapping to Assembler DSECT ?

2020-02-14 Thread Lionel B Dyck
Is this possible, and more importantly, has anyone done it and be willing to
share?

 

 

Lionel B. Dyck <
Website:   http://www.lbdsoftware.com

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

 


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


Re: Model9 is now backed by Intel Capital

2020-02-14 Thread David Crayford
So if it's running on zIIP does that mean it's a Java solution or are 
you doing some tricky magic?


On 2020-02-14 10:35 PM, Adi Shtatfeld wrote:

Hi John, Thank you for your comment.
One of our key differentiators is that our product allows you to save to
cloud any kind of data from the mainframe, whether it's data sets (VSAM,
PS, PDS, SMF) or databases (e.g. DB2). We can utilize any public and/or
private cloud as secondary storage, costing less than traditional tape
solutions. Transferring the data is not heavy on the mainframe, over 90% of
our CPU consumption is zIIP.
Best regards,
Adi


Adi Shtatfeld

VP Product & Customer Success, Model 9 Software

m: +972-54-4992774 e:adi.shtatf...@model9.io w:www.model9.io


On Thu, Feb 13, 2020 at 2:57 PM John Abell <
john.ab...@intnlsoftwareproducts.com> wrote:


Interesting but we have been doing this for CA IDMS database data for a
few years now.  Data is synchronized as near to real-time as is possible.
i.e. transaction end or commit.

John T. Abell
Tel:800-295-7608Option 4
President
International:  1-416-593-5578  Option 4
E-mail:  john.ab...@intnlsoftwareproducts.com
Fax:800-295-7609

International:  1-416-593-5579


International Software Products
www.ispinfo.com

This email may contain confidential and privileged material for the sole
use of the intended recipient(s). Any review, use, retention, distribution
or disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive on behalf of the named recipient),
please contact the sender by reply email and delete all copies of this
message. Also,email is susceptible to data corruption, interception,
tampering, unauthorized amendment and viruses. We only send and receive
emails on the basis that we are not liable for any such corruption,
interception, tampering, amendment or viruses or any consequence thereof.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Adi Shtatfeld
Sent: Thursday, February 13, 2020 3:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Model9 is now backed by Intel Capital


https://techcrunch.com/2020/02/12/model9-gets-9m-series-a-to-move-data-between-mainframes-and-cloud/


Adi Shtatfeld

VP Product & Customer Success, Model 9 Software

m: +972-54-4992774 e:adi.shtatf...@model9.io w:www.model9.io

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

2020-02-14 Thread Adi Shtatfeld
Hi John, Thank you for your comment.
One of our key differentiators is that our product allows you to save to
cloud any kind of data from the mainframe, whether it's data sets (VSAM,
PS, PDS, SMF) or databases (e.g. DB2). We can utilize any public and/or
private cloud as secondary storage, costing less than traditional tape
solutions. Transferring the data is not heavy on the mainframe, over 90% of
our CPU consumption is zIIP.
Best regards,
Adi


Adi Shtatfeld

VP Product & Customer Success, Model 9 Software

m: +972-54-4992774 e:adi.shtatf...@model9.io w:www.model9.io


On Thu, Feb 13, 2020 at 2:57 PM John Abell <
john.ab...@intnlsoftwareproducts.com> wrote:

> Interesting but we have been doing this for CA IDMS database data for a
> few years now.  Data is synchronized as near to real-time as is possible.
> i.e. transaction end or commit.
>
> John T. Abell
> Tel:800-295-7608Option 4
> President
> International:  1-416-593-5578  Option 4
> E-mail:  john.ab...@intnlsoftwareproducts.com
> Fax:800-295-7609
>
> International:  1-416-593-5579
>
>
> International Software Products
> www.ispinfo.com
>
> This email may contain confidential and privileged material for the sole
> use of the intended recipient(s). Any review, use, retention, distribution
> or disclosure by others is strictly prohibited. If you are not the intended
> recipient (or authorized to receive on behalf of the named recipient),
> please contact the sender by reply email and delete all copies of this
> message. Also,email is susceptible to data corruption, interception,
> tampering, unauthorized amendment and viruses. We only send and receive
> emails on the basis that we are not liable for any such corruption,
> interception, tampering, amendment or viruses or any consequence thereof.
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Adi Shtatfeld
> Sent: Thursday, February 13, 2020 3:37 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Model9 is now backed by Intel Capital
>
>
> https://techcrunch.com/2020/02/12/model9-gets-9m-series-a-to-move-data-between-mainframes-and-cloud/
>
>
> Adi Shtatfeld
>
> VP Product & Customer Success, Model 9 Software
>
> m: +972-54-4992774 e:adi.shtatf...@model9.io w:www.model9.io
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: 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