Re: RFE to enhance GDGORDER in JCL

[Elardus Engelbrecht]

Lizette Koehler wrote:

>I created my fist RFE, so be gentle.

"Really Fine Enhancement!" ;-D

>Use the GDGORDER parameter for a DD that specifies the base name of a GDG data 
>set (a GDG-all request). This keyword specifies the order in which the 
>individual generation data sets (GDSs) will be concatenated.

'Concatenated' - means you want to READ them in another order. No writing to 
GDG of course.

>This RFE is to request that the GDGORDER on JCL apply not only to the base but 
>the individual generation numbers as well.

That is a good RFE.

>If you think this would be beneficial, please vote.

I have. Only once! I want to vote 1 million times, but no... ;-)


J.P. wrote:

>"Your request is not going to end well. "

Really? This is an enhancement. Currently the logic is from youngest to oldest, 
but she wants to reverse the reading from the oldest to youngest. I believe 
there is a table (in the address space) used by that access method which gets 
all the GDG versions and then list them one by one based on available catalog 
entries and JCL DD entries at STEP level. After that, that list is then made 
available to the program in the JCL. All she asks is, simply reverse the order 
in a control block or area where that GDG version lists are stored temporarily.


Robert A. Rosenberg wrote:
 
>I can not see the RFE text to comment ...

Did you registered?

>IOW: //GDG  DD DISP=SHR,DSN=GDGBASE,GDGORDER=FIFO when there are 5 
generations yields:

Could work, but it is not always known that there are indeed 5 generations. 
Lizette wants the oldest and the access method should find that oldest entry no 
matter what the quantity of versions there are.

Currently as John said, only method is to get the GDG base, get the # of 
versions and move on from oldest to youngest. Tedious, but only method 
available which may or may not meddle with that DISP=(OLD,DELETE).

Good luck Lizette, you will need all the help. I remember your previous posts 
on this subject.

Groete / Greetings
Elardus Engelbrecht

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

Fault Analyzer and LE ABTERMENC

[Nick Baguley]

Hi List

 

We are seeing behaviour under fault analyser where the ABTERMENC LE runtime
option is being forced to RETCODE instead of ABEND.

 

Can anyone confirm the behaviour?

 

TIA

Nick



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

RFE to enhance GDGORDER in JCL

[Lizette Koehler]

I created my fist RFE, so be gentle.

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=81822

Use the GDGORDER parameter for a DD that specifies the base name of a GDG data 
set (a GDG-all request). This keyword specifies the order in which the 
individual generation data sets (GDSs) will be concatenated.

This RFE is to request that the GDGORDER on JCL apply not only to the base but 
the individual generation numbers as well.

For example.  If I code //GDG  DD DISP=SHR,DSN=GDGBASE,GDGORDER=FIFO   I can 
get to the oldest entry.
I would also like to see

//GDG  DD DISP=SHR,DSN=GDGBASE(0),GDGORDER=FIFO
//GDG  DD DISP=SHR,DSN=GDGBASE(-1),GDGORDER=FIFO
and so forth.

This is to allow the reading of GDG Base backwards and forward as well as get 
selected entries.

If you think this would be beneficial, please vote.

Thank you
Lizette

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

SMP/E error in my z/OS 2.1 Serverpac OS212016.

[Gibney, David Allen,Jr]

When I google HQX7790 I find this same error in a note dated August 11, 2015 
with subject SDSF z/os 2.1 - z/OS upgrade

  SET BDY(MVST100) .
GIM20501ISET PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 00.


UCLIN .

  DEL  SYSMOD(HQX7790) CIFREQ(
   (UI90005,UI90004)
  ) .
GIM25501IENTRY HQX7790 WAS UPDATED BY UCLIN.


  DEL  SYSMOD(HQX7790) CIFREQ(
   (UK96644,UK96643)
  ) .
GIM25301E ** SYSMOD ENTRY HQX7790 WAS NOT DELETED BECAUSE IT DOES NOT EXIST.
GIM25601ITHE SPECIFIED ENTRY WAS NOT UPDATED BECAUSE OF AN ERROR DURING
 UCLIN PROCESSING.


ENDUCL .

This is the first run of the restore job. And, yes, the job as generated has a 
redundant DEL which will fail if the first one works.

Now, I get to manually muck with this UCLIN and try to restart the restore job 
at this step.
Since this was after 501.16 MINUTES EXECUTION TIME, I'm not real interested in 
fixing the skeleton, regenning the job and starting from the top.

Dave Gibney
Information Technology Services
Washington State University


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

Re: RESTORE JOB on z/OS 2.1 Serverpac failing

[John Eells]

Would some kind soul please open a PMR?

An FMID is one type of SYSMOD.  SYSMODs include APARS, PTFS, FUNCTIONS 
(FMIDs), and USERMODs.


Lizette Koehler wrote:

Sharon,
Is HQX7790 a SYSMOD?  I might have thought it is an FMID.



--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: RESTORE JOB on z/OS 2.1 Serverpac failing

[Gibney, David Allen,Jr]

Service request number 86755 227 000 was successfully created with IBM support 
with the following title:

Duplicate DEL of SDSF (HQX7790)

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of John Eells
> Sent: Tuesday, January 12, 2016 1:33 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RESTORE JOB on z/OS 2.1 Serverpac failing
> 
> Would some kind soul please open a PMR?
> 
> An FMID is one type of SYSMOD.  SYSMODs include APARS, PTFS, FUNCTIONS
> (FMIDs), and USERMODs.
> 
> Lizette Koehler wrote:
> > Sharon,
> > Is HQX7790 a SYSMOD?  I might have thought it is an FMID.
> 
> 
> --
> John Eells
> IBM Poughkeepsie
> ee...@us.ibm.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: SMP/E error in my z/OS 2.1 Serverpac OS212016.

[Gibney, David Allen,Jr]

FYI, there is another set of DEL for HQX7790 a bit further down for the MVSD100 
zone.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Lopez, Sharon
> Sent: Tuesday, January 12, 2016 1:49 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMP/E error in my z/OS 2.1 Serverpac OS212016.
> 
> This is the answer from IBM; just in case anyone else might be experiencing
> this:
> 
> Due to recently added IFREQs, the ServerPac RESTORE job is not getting
> generated correctly, causing the errors. ServerPac development is currently
> in the process of fixing the RESTORE job generation error. As a workaround,
> you can RESTART the job from step UCLIN, removing all updates which were
> already done the previous run and also removing all occurences of statement
> DEL SYSMOD(HQX7790) CIFREQ( (UK96644,UK96643)).
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Gibney, David Allen,Jr
> Sent: Tuesday, January 12, 2016 4:13 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SMP/E error in my z/OS 2.1 Serverpac OS212016.
> 
> When I google HQX7790 I find this same error in a note dated August 11,
> 2015 with subject SDSF z/os 2.1 - z/OS upgrade
> 
>   SET BDY(MVST100) .
> GIM20501ISET PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE
> WAS 00.
> 
> 
> UCLIN .
> 
>   DEL  SYSMOD(HQX7790) CIFREQ(
>(UI90005,UI90004)
>   ) .
> GIM25501IENTRY HQX7790 WAS UPDATED BY UCLIN.
> 
> 
>   DEL  SYSMOD(HQX7790) CIFREQ(
>(UK96644,UK96643)
>   ) .
> GIM25301E ** SYSMOD ENTRY HQX7790 WAS NOT DELETED BECAUSE IT
> DOES NOT EXIST.
> GIM25601ITHE SPECIFIED ENTRY WAS NOT UPDATED BECAUSE OF AN
> ERROR DURING
>  UCLIN PROCESSING.
> 
> 
> ENDUCL .
> 
> This is the first run of the restore job. And, yes, the job as generated has a
> redundant DEL which will fail if the first one works.
> 
> Now, I get to manually muck with this UCLIN and try to restart the restore job
> at this step.
> Since this was after 501.16 MINUTES EXECUTION TIME, I'm not real
> interested in fixing the skeleton, regenning the job and starting from the 
> top.
> 
> Dave Gibney
> Information Technology Services
> Washington State University
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> 
> Email correspondence to and from this address may be subject to the North
> Carolina Public Records Law and may be disclosed to third parties by an
> authorized state official.
> 
> --
> 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: SMP/E error in my z/OS 2.1 Serverpac OS212016.

[Lopez, Sharon]

This is the answer from IBM; just in case anyone else might be experiencing 
this:

Due to recently added IFREQs, the ServerPac RESTORE job is not getting
generated correctly, causing the errors. ServerPac development is
currently in the process of fixing the RESTORE job generation error. As
a workaround, you can RESTART the job from step UCLIN, removing all
updates which were already done the previous run and also removing all 
occurences of statement DEL SYSMOD(HQX7790) CIFREQ( (UK96644,UK96643)).


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gibney, David Allen,Jr
Sent: Tuesday, January 12, 2016 4:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMP/E error in my z/OS 2.1 Serverpac OS212016.

When I google HQX7790 I find this same error in a note dated August 11, 2015 
with subject SDSF z/os 2.1 - z/OS upgrade

  SET BDY(MVST100) .
GIM20501ISET PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 00.


UCLIN .

  DEL  SYSMOD(HQX7790) CIFREQ(
   (UI90005,UI90004)
  ) .
GIM25501IENTRY HQX7790 WAS UPDATED BY UCLIN.


  DEL  SYSMOD(HQX7790) CIFREQ(
   (UK96644,UK96643)
  ) .
GIM25301E ** SYSMOD ENTRY HQX7790 WAS NOT DELETED BECAUSE IT DOES NOT EXIST.
GIM25601ITHE SPECIFIED ENTRY WAS NOT UPDATED BECAUSE OF AN ERROR DURING
 UCLIN PROCESSING.


ENDUCL .

This is the first run of the restore job. And, yes, the job as generated has a 
redundant DEL which will fail if the first one works.

Now, I get to manually muck with this UCLIN and try to restart the restore job 
at this step.
Since this was after 501.16 MINUTES EXECUTION TIME, I'm not real interested in 
fixing the skeleton, regenning the job and starting from the top.

Dave Gibney
Information Technology Services
Washington State University


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



Email correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.

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

Re: SMP/E error in my z/OS 2.1 Serverpac OS212016.

[Gibney, David Allen,Jr]

And also, in the following set of ADDs, it's also there twice.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Gibney, David Allen,Jr
> Sent: Tuesday, January 12, 2016 2:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMP/E error in my z/OS 2.1 Serverpac OS212016.
> 
> FYI, there is another set of DEL for HQX7790 a bit further down for the
> MVSD100 zone.
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-
> m...@listserv.ua.edu]
> > On Behalf Of Lopez, Sharon
> > Sent: Tuesday, January 12, 2016 1:49 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: SMP/E error in my z/OS 2.1 Serverpac OS212016.
> >
> > This is the answer from IBM; just in case anyone else might be
> > experiencing
> > this:
> >
> > Due to recently added IFREQs, the ServerPac RESTORE job is not getting
> > generated correctly, causing the errors. ServerPac development is
> > currently in the process of fixing the RESTORE job generation error.
> > As a workaround, you can RESTART the job from step UCLIN, removing all
> > updates which were already done the previous run and also removing all
> > occurences of statement DEL SYSMOD(HQX7790) CIFREQ(
> (UK96644,UK96643)).
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-
> m...@listserv.ua.edu]
> > On Behalf Of Gibney, David Allen,Jr
> > Sent: Tuesday, January 12, 2016 4:13 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: SMP/E error in my z/OS 2.1 Serverpac OS212016.
> >
> > When I google HQX7790 I find this same error in a note dated August
> > 11,
> > 2015 with subject SDSF z/os 2.1 - z/OS upgrade
> >
> >   SET BDY(MVST100) .
> > GIM20501ISET PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE
> > WAS 00.
> >
> >
> > UCLIN .
> >
> >   DEL  SYSMOD(HQX7790) CIFREQ(
> >(UI90005,UI90004)
> >   ) .
> > GIM25501IENTRY HQX7790 WAS UPDATED BY UCLIN.
> >
> >
> >   DEL  SYSMOD(HQX7790) CIFREQ(
> >(UK96644,UK96643)
> >   ) .
> > GIM25301E ** SYSMOD ENTRY HQX7790 WAS NOT DELETED BECAUSE IT
> DOES NOT
> > EXIST.
> > GIM25601ITHE SPECIFIED ENTRY WAS NOT UPDATED BECAUSE OF AN
> > ERROR DURING
> >  UCLIN PROCESSING.
> >
> >
> > ENDUCL .
> >
> > This is the first run of the restore job. And, yes, the job as
> > generated has a redundant DEL which will fail if the first one works.
> >
> > Now, I get to manually muck with this UCLIN and try to restart the
> > restore job at this step.
> > Since this was after 501.16 MINUTES EXECUTION TIME, I'm not real
> > interested in fixing the skeleton, regenning the job and starting from the
> top.
> >
> > Dave Gibney
> > Information Technology Services
> > Washington State University
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > 
> >
> > Email correspondence to and from this address may be subject to the
> > North Carolina Public Records Law and may be disclosed to third
> > parties by an authorized state official.
> >
> > --
> > 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: RESTORE JOB on z/OS 2.1 Serverpac failing

[Gibney, David Allen,Jr]

And I see I am still not alone. HQX7790 is SDSF. Ignoring this message is ok as 
far as I can tell, but there is incomplete work in the UCLIN step and the 
following steps that needs to be completed.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Jakubek, Jan
> Sent: Tuesday, January 12, 2016 1:08 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RESTORE JOB on z/OS 2.1 Serverpac failing
> 
> I got this message as well. I simply ignored it.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Lopez, Sharon
> Sent: Tuesday, January 12, 2016 3:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: RESTORE JOB on z/OS 2.1 Serverpac failing
> 
> I saw that someone else had posted this same thing back in August; but I did
> not see a resolution.  Has anyone else encountered this with the RESTORE job
> in the z/OS 2.1 Serverpac Install.  I've opened up a ticket with IBM but being
> the impatient type, I thought I would ask the LIST-SERVE.
> Thank you.
> 
> 
>DEL  SYSMOD(HQX7790) CIFREQ(
>(UK96644,UK96643)
>   ) .
> GIM25301E ** SYSMOD ENTRY HQX7790 WAS NOT DELETED BECAUSE IT
> DOES NOT EXIST.
> GIM25601ITHE SPECIFIED ENTRY WAS NOT UPDATED BECAUSE OF AN
> ERROR DURING
>  UCLIN PROCESSING.
> 
> 
> 
> 
> 
> Email correspondence to and from this address may be subject to the North
> Carolina Public Records Law and may be disclosed to third parties by an
> authorized state official.
> 
> --
> 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: RESTORE JOB on z/OS 2.1 Serverpac failing

[Gibney, David Allen,Jr]

OK
Your service request is in process. Until it reaches the IBM support team, its 
service request number will display as In process on your IBM Service Request 
home page. If you have any questions, please contact the IBM Service Request 
help desk.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of John Eells
> Sent: Tuesday, January 12, 2016 1:33 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RESTORE JOB on z/OS 2.1 Serverpac failing
> 
> Would some kind soul please open a PMR?
> 
> An FMID is one type of SYSMOD.  SYSMODs include APARS, PTFS, FUNCTIONS
> (FMIDs), and USERMODs.
> 
> Lizette Koehler wrote:
> > Sharon,
> > Is HQX7790 a SYSMOD?  I might have thought it is an FMID.
> 
> 
> --
> John Eells
> IBM Poughkeepsie
> ee...@us.ibm.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: SMP/E error in my z/OS 2.1 Serverpac OS212016.

[Paul Gilmartin]

On 2016-01-12 15:03, Gibney, David Allen,Jr wrote:
> And also, in the following set of ADDs, it's also there twice.
>  ...
Well, if they'd just *alternate* the ADDs with the DELETEs, they'd all work.

-- gil

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

Re: Reflection FTP Client - Secure

[Roach, Dennis]

And the answer is RTFM. It is setup in the Tectia config file which has both a 
system and user level.

Dennis Roach, CISSP, PMP
IAM Access Administration - Consumer - Senior Analyst 
2727 Allen Parkway, Wortham Building 3rd Floor, Houston, TX 77019
Work:  713-831-8799
Cell:  713-591-1059
Email:  dennis.ro...@aig.com 
Report information security incidents to: aiglr_security_incide...@aig.com and 
(818) 673-4030 

All opinions expressed by me are mine and may not agree with my employer or any 
person, company, or thing, living or dead, on or near this or any other planet, 
moon, asteroid, or other spatial object, natural or manufactured, since the 
beginning of time.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Finnell
Sent: Tuesday, January 12, 2016 3:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Reflection FTP Client - Secure

Not Reflection. Use ws_ftp from _www.ipswitch.com_
(http://www.ipswitch.com)  and it has a pulldown for to  and from side for OS 
type with a default parm of Autodetect. Get's it right most  of the time.
 
 
In a message dated 1/12/2016 2:52:29 P.M. Central Standard Time,  
dennis.ro...@aig.com writes:

It works  great for binary transfers, but I cannot get it to translate 
EBCDIC/ASCII. Has  anyone been successful with this?  


--
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: RFE to enhance GDGORDER in JCL

[J. P.]

You are asking IBM to provide a new access method to read the file(s) backward 
with your request.  And there is no guarantee that the actual access method 
invoked by the program(s) involved will be compatible with your new backwards 
access method (lets call it LBAM, shall we?).  For example, the program might 
be written to use BSAM (or even EXCP) while your new LBAM is only setup to 
support QSAM.  
  
Your request is not going to end well.  
  
J.P. 
  
Lizette recently posted: 

I created my first RFE, so be gentle.

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=81822

Use the GDGORDER parameter for a DD that specifies the base name of a GDG data 
set (a GDG-all request). This keyword specifies the order in which the 
individual generation data sets (GDSs) will be concatenated.

This RFE is to request that the GDGORDER on JCL apply not only to the base but 
the individual generation numbers as well.

For example.  If I code //GDG  DD DISP=SHR,DSN=GDGBASE,GDGORDER=FIFO   I can 
get to the oldest entry.
I would also like to see

//GDG  DD DISP=SHR,DSN=GDGBASE(0),GDGORDER=FIFO
//GDG  DD DISP=SHR,DSN=GDGBASE(-1),GDGORDER=FIFO
and so forth.

This is to allow the reading of GDG Base backwards and forward as well as get 
selected entries.

If you think this would be beneficial, please vote.

Thank you
Lizette

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

Re: RFE to enhance GDGORDER in JCL

[John McKown]

On Tue, Jan 12, 2016 at 2:06 PM, J. P.  wrote:

> You are asking IBM to provide a new access method to read the file(s)
> backward with your request.  And there is no guarantee that the actual
> access method invoked by the program(s) involved will be compatible with
> your new backwards access method (lets call it LBAM, shall we?).  For
> example, the program might be written to use BSAM (or even EXCP) while your
> new LBAM is only setup to support QSAM.
>

​I don't think that's what ​Lizette is asking for. Assume that there exists
GDG.G0002V00 through GDG.G0007V00 in the GDS. Normally GDG(0) gets you
GDG.G0007V00. That is the _highest_ "goovoo" number in the GDS. Lizette
wants a way to do a relative generation ask for the _lowest_ "goovoo" in
the GDS. So that it would be possible have a series of identical jobs run
to process each member of the GDS from "oldest" to "newest". I.e.

//SOMESTEP EXEC PGM=SOMEPROG
//SYSPRINT DD SYSOUT=*
//INPUT DD DISP=(OLD,DELETE),DSN=GDG(0),GDGORDER=FIFO

In the above, the first time the job with the step is run, GDG.G0002V00 is
processed and deleted. The second time it is run, GDG.G0003V00 is processed
and deleted. And so forth. There is no way to do this using current JCL.
The only way that I know is to run something which does in inquire on the
GDS, get the oldest GDS entry, then do a dynamic allocate on it, and
finally process it.


>
> Your request is not going to end well.
>
> J.P.
>
> Lizette recently posted:
>
> I created my first RFE, so be gentle.
>
> http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=81822
>
> Use the GDGORDER parameter for a DD that specifies the base name of a GDG
> data set (a GDG-all request). This keyword specifies the order in which the
> individual generation data sets (GDSs) will be concatenated.
>
> This RFE is to request that the GDGORDER on JCL apply not only to the base
> but the individual generation numbers as well.
>
> For example.  If I code //GDG  DD DISP=SHR,DSN=GDGBASE,GDGORDER=FIFO   I
> can get to the oldest entry.
> I would also like to see
>
> //GDG  DD DISP=SHR,DSN=GDGBASE(0),GDGORDER=FIFO
> //GDG  DD DISP=SHR,DSN=GDGBASE(-1),GDGORDER=FIFO
> and so forth.
>
> This is to allow the reading of GDG Base backwards and forward as well as
> get selected entries.
>
> If you think this would be beneficial, please vote.
>
> Thank you
> Lizette
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Werner Heisenberg is driving down the autobahn. A police officer pulls
him over. The officer says, "Excuse me, sir, do you know how fast you
were going?"
"No," replies Dr. Heisenberg, "but I know where I am."

Computer Science is the only discipline in which we view adding a new wing
to a building as being maintenance -- Jim Horning

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

He's about as useful as a wax frying pan.

Maranatha! <><
John McKown

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

Fw: Re: RFE to enhance GDGORDER in JCL

[Lizette Koehler]

IBM is already supplying the process to read the oldest or the newest with 
GDGORDER=LIFO or GDGORDER=FIFO.  I am just asking that they allow the GDGORDER 
to pick up the GDG relative number where GDGORDER is specified (LIFO is the 
default so -1, -2 would behave the same).  I am asking if GDGORDER=FIFO is 
specified, that it also be used with the relative gen number.

So with John's example G0001V00 - G0007V00.

//GDGDD  DD DISP=SHR,DSN=GDGBASE(0)   = G0007V00

//GDGDD  DD DISP=SHR,DSN=GDGBASE(-1)  = G0006V00  

//GDGDD  DD DISP=SHR,DSN=GDGBASE(0),GDGORDER=FIFO   = G0001V00 

//GDGDD  DD DISP=SHR,DSN=GDGBASE(-1),GDGORDER=FIFO  = G0002V00 

  I did not ask for a new way to specify the Relative Gen number.  So I would 
expect the user would need to be careful when reading oldest to youngest.  Same 
errors should occur should a user ask for the GDGORDER=FIFO with -3 and -3 does 
not exist.

and so on.

GDGORDER only reads the base backwards.  I wanted something that could target a 
relative GDG Number forwards or backwards.

I did open a case to IBM on this, and they suggested the RFE since they liked 
the idea.

Lizette
 

-Original Message-
>From: "J. P." 
>Sent: Jan 12, 2016 1:06 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: RFE to enhance GDGORDER in JCL
>
>You are asking IBM to provide a new access method to read the file(s) backward 
>with your request.  And there is no guarantee that the actual access method 
>invoked by the program(s) involved will be compatible with your new backwards 
>access method (lets call it LBAM, shall we?).  For example, the program might 
>be written to use BSAM (or even EXCP) while your new LBAM is only setup to 
>support QSAM.  
>  
>Your request is not going to end well.  
>  
>J.P. 
>

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

Re: RFE to enhance GDGORDER in JCL

[Robert A. Rosenberg]

I can not see the RFE text to comment but from the description I see 
nothing about the order of reading the records in the generation but 
only the order of the generations in the concatenation.


IOW: //GDG  DD DISP=SHR,DSN=GDGBASE,GDGORDER=FIFO when there are 5 
generations yields:


//GDG  DD DISP=SHR,DSN=GDGBASE(-4)
// DD DISP=SHR,DSN=GDGBASE(-3)
// DD DISP=SHR,DSN=GDGBASE(-2)
// DD DISP=SHR,DSN=GDGBASE(-1)
// DD DISP=SHR,DSN=GDGBASE(0)

This has the advantage that you do not need to list each relative 
generation (as above) and/or need to know the generation count.



At 14:06 -0600 on 01/12/2016, J. P. wrote about Re: RFE to enhance 
GDGORDER in JCL:


You are asking IBM to provide a new access method to read the 
file(s) backward with your request.  And there is no guarantee that 
the actual access method invoked by the program(s) involved will be 
compatible with your new backwards access method (lets call it LBAM, 
shall we?).  For example, the program might be written to use BSAM 
(or even EXCP) while your new LBAM is only setup to support QSAM. 


Your request is not going to end well. 

J.P.

Lizette recently posted:

I created my first RFE, so be gentle.

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=81822

Use the GDGORDER parameter for a DD that specifies the base name of 
a GDG data set (a GDG-all request). This keyword specifies the order 
in which the individual generation data sets (GDSs) will be 
concatenated.


This RFE is to request that the GDGORDER on JCL apply not only to 
the base but the individual generation numbers as well.


For example.  If I codeI can get to the oldest entry.
I would also like to see

//GDG  DD DISP=SHR,DSN=GDGBASE(0),GDGORDER=FIFO
//GDG  DD DISP=SHR,DSN=GDGBASE(-1),GDGORDER=FIFO
and so forth.

This is to allow the reading of GDG Base backwards and forward as 
well as get selected entries.


If you think this would be beneficial, please vote.

Thank you
Lizette

--
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: RESTORE JOB on z/OS 2.1 Serverpac failing

[Jakubek, Jan]

I got this message as well. I simply ignored it.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lopez, Sharon
Sent: Tuesday, January 12, 2016 3:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RESTORE JOB on z/OS 2.1 Serverpac failing

I saw that someone else had posted this same thing back in August; but I did 
not see a resolution.  Has anyone else encountered this with the RESTORE job in 
the z/OS 2.1 Serverpac Install.  I've opened up a ticket with IBM but being the 
impatient type, I thought I would ask the LIST-SERVE.
Thank you.


   DEL  SYSMOD(HQX7790) CIFREQ(
   (UK96644,UK96643)
  ) .
GIM25301E ** SYSMOD ENTRY HQX7790 WAS NOT DELETED BECAUSE IT DOES NOT EXIST.
GIM25601ITHE SPECIFIED ENTRY WAS NOT UPDATED BECAUSE OF AN ERROR DURING
 UCLIN PROCESSING.





Email correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.

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

RESTORE JOB on z/OS 2.1 Serverpac failing

[Lopez, Sharon]

I saw that someone else had posted this same thing back in August; but I did 
not see a resolution.  Has anyone else encountered this with the RESTORE job in 
the z/OS 2.1 Serverpac Install.  I've opened up a ticket with IBM but being the 
impatient type, I thought I would ask the LIST-SERVE.
Thank you.


   DEL  SYSMOD(HQX7790) CIFREQ(
   (UK96644,UK96643)
  ) .
GIM25301E ** SYSMOD ENTRY HQX7790 WAS NOT DELETED BECAUSE IT DOES NOT EXIST.
GIM25601ITHE SPECIFIED ENTRY WAS NOT UPDATED BECAUSE OF AN ERROR DURING
 UCLIN PROCESSING.





Email correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.

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

Re: RESTORE JOB on z/OS 2.1 Serverpac failing

[Lizette Koehler]

Sharon,
Is HQX7790 a SYSMOD?  I might have thought it is an FMID.
Lizette


-Original Message-
>From: "Lopez, Sharon" 
>Sent: Jan 12, 2016 1:36 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: RESTORE JOB on z/OS 2.1 Serverpac failing
>
>I saw that someone else had posted this same thing back in August; but I did 
>not see a resolution.  Has anyone else encountered this with the RESTORE job 
>in the z/OS 2.1 Serverpac Install.  I've opened up a ticket with IBM but being 
>the impatient type, I thought I would ask the LIST-SERVE.
>Thank you.
>
>
>   DEL  SYSMOD(HQX7790) CIFREQ(
>   (UK96644,UK96643)
>  ) .
>GIM25301E ** SYSMOD ENTRY HQX7790 WAS NOT DELETED BECAUSE IT DOES NOT EXIST.
>GIM25601ITHE SPECIFIED ENTRY WAS NOT UPDATED BECAUSE OF AN ERROR DURING
> UCLIN PROCESSING.
>
>

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

Reflection FTP Client - Secure

[Roach, Dennis]

We currently use Reflection FTP Client for standard, non-secure, ftp. We 
installed Tectia secure shell ftp. I can get Reflection to sign-on to Tectia 
using certificates. It works great for binary transfers, but I cannot get it to 
translate EBCDIC/ASCII. Has anyone been successful with this? 
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Reflection FTP Client - Secure

[Ed Finnell]

Not Reflection. Use ws_ftp from _www.ipswitch.com_ 
(http://www.ipswitch.com)  and it has a pulldown for to  and from side for OS 
type with a default 
parm of Autodetect. Get's it right most  of the time.
 
 
In a message dated 1/12/2016 2:52:29 P.M. Central Standard Time,  
dennis.ro...@aig.com writes:

It works  great for binary transfers, but I cannot get it to translate 
EBCDIC/ASCII. Has  anyone been successful with this?  


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

Conversion from Unisys Cobol file definitions to zOS

[Ambros, Thomas]

My apologies if there is a Cobol listserv that I should have subscribed to and 
submitted the question there, if someone knows of it please let me know so I 
can redirect to the correct place.  

Pardon me, also, if I use terms incorrectly in phrasing my question because I 
couldn't be weaker in application programming or Cobol idiosyncracies. 

Our site has occasion to import files from a Unisys site running 'MCP Level 57 
Miser level 15.2', and integrate the data with the application datasets on the 
local system.  I do not know the Cobol product the Unisys site is using, I have 
inquiries out but no answers yet.  There are at least a few items causing our 
application programmers some difficulties.  

For example, it appears that the COMP fields in the Unisys file do not occupy 
storage the same as they do on zOS.   For example, a COMP field with three 
digits occupies one and one-half bytes on the Unisys file whereas on zOS it 
would be a halfword.  

Given the size and number of the files and descriptions to convert, coding a 
conversion by hand is not entirely practical.  

I realize this is a pretty vague request, but does anyone know of a conversion 
utility or compiler directive to make the translation from the Unisys 
implementation of Cobol FD's to Enterprise Cobol?   I have done some basic 
Google searching but nothing I find appears to address this sort of thing very 
closely. 

Thomas Ambros
zEnterprise Operating Systems
zEnterprise Systems Management
518-436-6433





This communication may contain privileged and/or confidential information. It 
is intended solely for the use of the addressee. If you are not the intended 
recipient, you are strictly prohibited from disclosing, copying, distributing 
or using any of this information. If you received this communication in error, 
please contact the sender immediately and destroy the material in its entirety, 
whether electronic or hard copy. This communication may contain nonpublic 
personal information about consumers subject to the restrictions of the 
Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose 
such information for any purpose other than to provide the services for which 
you are receiving the information.

127 Public Square, Cleveland, OH 44114
If you prefer not to receive future e-mail offers for products or services from 
Key 
send an e-mail to mailto:dnereque...@key.com with 'No Promotional E-mails' in 
the 
SUBJECT line.

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

Partition usage

[R.S.]

In HCD there are 3 options:
OS
CF
CF/OS

Obviously CF means Coupling Facility, while OS is Operating System 
(non-CFCC), but what is the difference between above modes?

Any reason to not use CF/OS everywhere?

--
Radoslaw Skorupka
Lodz, Poland






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

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

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


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

Re: Reflection FTP Client - Secure

[Ed Finnell]

Great. Glad it was straightforward.
 
 
In a message dated 1/12/2016 4:12:02 P.M. Central Standard Time,  
dennis.ro...@aig.com writes:

It is  setup in the Tectia config file which has both a system and user  
level.


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

Re: Sharing of consoles

[John Sawyer]

Hi Sharon,

I don't want to be invasive, but I saw your question about console sharing, and 
an earlier one about FIPS 140-2 compliance.

SecureAgent Software provides a mainframe solution with full FIPS 140-2 
Certification that provides secure, encrypted mainframe connections across 
multiple data centers.  It is the preferred solution for CitiBank, VISA, 
Fidelity, and many others.

It is also in use by both Federal and State government agencies.  We also have 
a GSA schedule we use as a vehicle to sell to various Government Agencies.

I don't mean to bug you, but if you are interested in more information you can 
reach me at:

john.saw...@mail.secureagent.com  or call me at 
918.691.9000

Thanks and have a good evening!

John Sawyer

 
On Jan 6, 2016, at 11:18 AM, Lopez, Sharon wrote:

> What console controllers does everyone use to share consoles across multiple 
> data centers?  Are most people using OSA, Visara controllers, etc?
> 
> Thank you.
> 
> Sharon Lopez
> 
> 
> 
> Email correspondence to and from this address may be subject to the North 
> Carolina Public Records Law and may be disclosed to third parties by an 
> authorized state official.
> 
> --
> 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: Conversion from Unisys Cobol file definitions to zOS

[Mitch Mccluhan]

 Tom,

Contact me offline on this via email.  I am in the process of doing the same 
thing for a client on the east coast.

Regards,

 

Mitch McCluhan
mitc...@aol.com

 

 

-Original Message-
From: Ambros, Thomas 
To: IBM-MAIN 
Sent: Tue, Jan 12, 2016 10:05 am
Subject: Conversion from Unisys Cobol file definitions to zOS

My apologies if there is a Cobol listserv that I should have subscribed to and 
submitted the question there, if someone knows of it please let me know so I 
can redirect to the correct place.  

Pardon me, also, if I use terms incorrectly in phrasing my question because I 
couldn't be weaker in application programming or Cobol idiosyncracies. 

Our site has occasion to import files from a Unisys site running 'MCP Level 57 
Miser level 15.2', and integrate the data with the application datasets on the 
local system.  I do not know the Cobol product the Unisys site is using, I have 
inquiries out but no answers yet.  There are at least a few items causing our 
application programmers some difficulties.  

For example, it appears that the COMP fields in the Unisys file do not occupy 
storage the same as they do on zOS.   For example, a COMP field with three 
digits occupies one and one-half bytes on the Unisys file whereas on zOS it 
would be a halfword.  

Given the size and number of the files and descriptions to convert, coding a 
conversion by hand is not entirely practical.  

I realize this is a pretty vague request, but does anyone know of a conversion 
utility or compiler directive to make the translation from the Unisys 
implementation of Cobol FD's to Enterprise Cobol?   I have done some basic 
Google searching but nothing I find appears to address this sort of thing very 
closely. 

Thomas Ambros
zEnterprise Operating Systems
zEnterprise Systems Management
518-436-6433





This communication may contain privileged and/or confidential information. It 
is intended solely for the use of the addressee. If you are not the intended 
recipient, you are strictly prohibited from disclosing, copying, distributing 
or using any of this information. If you received this communication in error, 
please contact the sender immediately and destroy the material in its entirety, 
whether electronic or hard copy. This communication may contain nonpublic 
personal information about consumers subject to the restrictions of the 
Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose 
such information for any purpose other than to provide the services for which 
you are receiving the information.

127 Public Square, Cleveland, OH 44114
If you prefer not to receive future e-mail offers for products or services from 
Key 
send an e-mail to mailto:dnereque...@key.com with 'No Promotional E-mails' in 
the 
SUBJECT line.

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