Re: IEC141I 013-A8: how to read VS data sets?

[Bill Woodger]

The S in FS is the same "standard" as the S in FBS.

With an F which has been MODded there will, mostly, be an unfilled track (last 
record on from the previous output, empty remainder of track unless the record 
happens to be the last one which would fit on a track).

FS guarantees (by the person who coded it) that there is no partial track 
within the file/data set, so that a record can be read directly through the 
calculation of its position. As far as I know, it is simply that guarantee that 
is the difference, so it can be acted upon. S meaning "this data set has not 
been MODded, and if it has, it is my fault that something goes to pot at times".

As far as I know, the S in FS and FBS are not mandatory when writing, and 
everything works when it is specified for the data set used as input.

Although the "S" is a "performance thing", it is only so for "seek-type" usage 
(I'm sure there is a "calculate my physical record's location" Assemble macro). 
It otherwise makes no difference.

I think SAS has some stipulations about FBS for its libraries, or some of them.

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

Re: (External):Re: IEC141I 013-A8: how to read VS data sets?

[Jesse 1 Robinson]

From the trivia-I-happen-to-know drawer. Classic CA-1 (at least used to) use an 
unblocked RECFM=F data base so that records could be managed in the same way. 
So tape volser 123456 would be the 123,456th record in the data base. Made for 
a gigantic data base, but processing was very quick without having to manage an 
elaborate direct access method. 

That empties the drawer.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Woodger
Sent: Thursday, January 05, 2017 5:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IEC141I 013-A8: how to read VS data sets?

Yet in modern times the S for F has its uses. If a C/C++ program is going to 
use a "seek" for a file, if the file is F/FB, then the file will be read from 
the start to satisfy the seek (because there may be those embedded short 
blocks), but if the file is FS/FBS (guarantee, by the person who put the S in 
the RECFM, to not have embedded short blocks) then the seek is able to 
calculate the position of he block containing the sought record, and then only 
have to read within the block.

I'm sure all C/C++ programmers who want to use seek on z/OS know that, since it 
is documented. Yeah. Right. (at risk of starting war) people who want to code 
seek to save a bit of thinking are exactly the ones who read the manuals.

What this means is "if you are using seek in a C/C++ program to access 
fixed-length records, ensure RECFM=FS/FBS. If you haven't done that, do it, and 
compare the resource usage.


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

Re: IEC141I 013-A8: how to read VS data sets?

[Jesse 1 Robinson]

I don't think 'FS' is meaningful. Not wrong, just pointless. If unblocked, all 
blocks contain exactly one record. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of J R
Sent: Thursday, January 05, 2017 5:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IEC141I 013-A8: how to read VS data sets?

What does RECFM=FS mean?  
How does it differ from RECFM=F?  

Sent from my iPhone

> On Jan 5, 2017, at 20:12, Bill Woodger  wrote:
> 
> Yet in modern times the S for F has its uses. If a C/C++ program is going to 
> use a "seek" for a file, if the file is F/FB, then the file will be read from 
> the start to satisfy the seek (because there may be those embedded short 
> blocks), but if the file is FS/FBS (guarantee, by the person who put the S in 
> the RECFM, to not have embedded short blocks) then the seek is able to 
> calculate the position of he block containing the sought record, and then 
> only have to read within the block.
> 
> I'm sure all C/C++ programmers who want to use seek on z/OS know that, since 
> it is documented. Yeah. Right. (at risk of starting war) people who want to 
> code seek to save a bit of thinking are exactly the ones who read the manuals.
> 
> What this means is "if you are using seek in a C/C++ program to access 
> fixed-length records, ensure RECFM=FS/FBS. If you haven't done that, do it, 
> and compare the resource usage.


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

Re: IEC141I 013-A8: how to read VS data sets?

[J R]

What does RECFM=FS mean?  
How does it differ from RECFM=F?  

Sent from my iPhone

> On Jan 5, 2017, at 20:12, Bill Woodger  wrote:
> 
> Yet in modern times the S for F has its uses. If a C/C++ program is going to 
> use a "seek" for a file, if the file is F/FB, then the file will be read from 
> the start to satisfy the seek (because there may be those embedded short 
> blocks), but if the file is FS/FBS (guarantee, by the person who put the S in 
> the RECFM, to not have embedded short blocks) then the seek is able to 
> calculate the position of he block containing the sought record, and then 
> only have to read within the block.
> 
> I'm sure all C/C++ programmers who want to use seek on z/OS know that, since 
> it is documented. Yeah. Right. (at risk of starting war) people who want to 
> code seek to save a bit of thinking are exactly the ones who read the manuals.
> 
> What this means is "if you are using seek in a C/C++ program to access 
> fixed-length records, ensure RECFM=FS/FBS. If you haven't done that, do it, 
> and compare the resource usage.
> 
> --
> 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: IEC141I 013-A8: how to read VS data sets?

[Bill Woodger]

Yet in modern times the S for F has its uses. If a C/C++ program is going to 
use a "seek" for a file, if the file is F/FB, then the file will be read from 
the start to satisfy the seek (because there may be those embedded short 
blocks), but if the file is FS/FBS (guarantee, by the person who put the S in 
the RECFM, to not have embedded short blocks) then the seek is able to 
calculate the position of he block containing the sought record, and then only 
have to read within the block.

I'm sure all C/C++ programmers who want to use seek on z/OS know that, since it 
is documented. Yeah. Right. (at risk of starting war) people who want to code 
seek to save a bit of thinking are exactly the ones who read the manuals.

What this means is "if you are using seek in a C/C++ program to access 
fixed-length records, ensure RECFM=FS/FBS. If you haven't done that, do it, and 
compare the resource usage.

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

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Tony Harminc]

On 5 January 2017 at 12:38, Pommier, Rex  wrote:
> 2)  $BR1 in M gives me "lots" of good information .
> The doc says "JES2 initialization processing encountered an error examining 
> the BERT maps" and the resolution is "
> Use the indicative dump and the SVC dump (if any) to diagnose the error.".

What's the reason code with the $BR1?

Tony H.

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

Re: IEC141I 013-A8: how to read VS data sets?

[Jesse 1 Robinson]

Pretty much I would say. Just want to point out that FBS and VBS are worlds 
apart. As discussed, the 'S' in VBS is 'spanned'. The 'S' in FBS means 
'standard' or some such. This guarantees that the file has no short blocks 
other than the very last one. A file written 'normally' is usually FBS whether 
labeled that way or not, but one written to multiple times via DISP=MOD is 
almost certain to have many short blocks, one for each time the file is closed 
and then reopened. 

I doubt that modern processing really cares, but once upon a time FBS was more 
efficient than FB to read because I/O routines did not have to check for and 
handle a short block on every read. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Woodger
Sent: Thursday, January 05, 2017 4:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IEC141I 013-A8: how to read VS data sets?

Paul,

For QSAM, there's F/FS/FB/FBS, U, V/VB, VS/VBS that you may see used in a 
business system (and business systems, in the main, are the reasons for having 
a Mainframe).

All have their specific "it's better in this case to do this". Of these, VS/VBS 
is the slowest way to read or write records, and the least likely that you will 
see, and the least "known" to programmers, in business systems.

"Slowest" means, for large numbers of records (the usual stuff of Mainframe 
business systems) "more expensive" and "running longer". Neither of these are 
good.

I've seen you suggest that things would be better with VS/VBS only: can you 
outline how, please?

QSAM has limits. You seem to be unable to accept that. It has the limits it 
has, not the limits that you think it should have. It ain't gonna change.

If for your "more and more mysterious" your point is "why didn't it abend, 
rather than apparently work, although work other than I wanted", then raise it 
with IBM. I'm not sure it will get a high priority, because mostly people will 
be expected to respect the limits.

Since you are very much at home with HFS, why don't you use that, and just 
pretend that it is giving you VS/VBS? Won't that make you happy, and leave 
everyone else choosing the most effective RECFM for the specific task (or not, 
as it has been known to happen)? 


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

Re: IEC141I 013-A8: how to read VS data sets?

[Bill Woodger]

Paul,

For QSAM, there's F/FS/FB/FBS, U, V/VB, VS/VBS that you may see used in a 
business system (and business systems, in the main, are the reasons for having 
a Mainframe).

All have their specific "it's better in this case to do this". Of these, VS/VBS 
is the slowest way to read or write records, and the least likely that you will 
see, and the least "known" to programmers, in business systems.

"Slowest" means, for large numbers of records (the usual stuff of Mainframe 
business systems) "more expensive" and "running longer". Neither of these are 
good.

I've seen you suggest that things would be better with VS/VBS only: can you 
outline how, please?

QSAM has limits. You seem to be unable to accept that. It has the limits it 
has, not the limits that you think it should have. It ain't gonna change.

If for your "more and more mysterious" your point is "why didn't it abend, 
rather than apparently work, although work other than I wanted", then raise it 
with IBM. I'm not sure it will get a high priority, because mostly people will 
be expected to respect the limits.

Since you are very much at home with HFS, why don't you use that, and just 
pretend that it is giving you VS/VBS? Won't that make you happy, and leave 
everyone else choosing the most effective RECFM for the specific task (or not, 
as it has been known to happen)?

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

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Longabaugh, Robert E]

A sysmod can have more than one ++VER.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Thursday, January 05, 2017 4:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error

We’re drifting a bit here, but I had to look up ++VER to see whether a single 
PTF could be installed on more than base FMID. I find 

'-FMID--(--sysmod_id--)-'

I have never made peace with railroad track diagrams, but I think this means 
that only one base FMID can be specified. I don't see recursion. (Hate RR.)   

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Thursday, January 05, 2017 10:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
catastrophic error

On Thu, 5 Jan 2017 11:26:51 -0600, Art Gutowski wrote:

>... it probably wouldn't hurt to do a REPORT SYSMODS <1.13 zone>
>COMPAREDTO(<2.2 zone>) and vice versa.

Is that going to give you any useful information, Art? I believe that it is 
possible to code the ++VER in a PTF so that the same PTF can be applied to two 
different FMIDs, but I can't remember ever seeing it.

Of course, I have been wrong before...

--
Tom Marchant


--
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: IEC141I 013-A8: how to read VS data sets?

[Paul Gilmartin]

On 2017-01-05, at 14:47, Jesse 1 Robinson wrote:
> 
> If a JES2 output segment is created with 'VS' attributes, that does not mean 
> that the data on spool actually consists of spanned records. The point of 
> spanning is to manage records that can exceed physical block size, e.g. 
> 32760. SMF can potentially do that because so many records can have unlimited 
> segments. What does physical block size even mean to JES? 
> 
However, the venerable access methods rely on halfword descriptors
both in the data and in control blocks.  So if the spool is to be
compatible with those access methods it must support their RECFMs,
even including VBS.

It's a pity.  VBS should have been the only RECFM anyone ever needed,
thus the only one ever defined and supported.  Everything could have
been the same.

Mysteriouser and mysteriouser:  I allocated a couple data sets each
with JCL and BPXWDYN.  Then, with EXECIO I wrote one record to one
member of each pair.  Magically, LRECL shrank to 32756.  I may have
discussed this behavior long ago in one of these fora.  I don't
remember the explanation, if any.

 DSLIST - Data Sets Matching User.TEMP.V*Row 1 of 4 
 Command ===>  Scroll ===> CSR  
 Command - Enter "/" to select action Dsorg  Recfm  Lrecl  Blksz
 ---
  User.TEMP.VBSDYN   VBS32760  0
  User.TEMP.VBSDYNWPSVBS32756  27998
  User.TEMP.VBSJCL   VBS32761  0
  User.TEMP.VBSJCLWPSVBS32756  27998
 * End of Data Set list 

--gil

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

Re: IEC141I 013-A8: how to read VS data sets?

[Lizette Koehler]

 
  http://www.redbooks.ibm.com/abstracts/sg247419.html
   SDSF REXX Redbook

Providing REXX programs with an API to access IBM z/OS System Display and
Search Facility (SDSF) functions gives you a powerful tool for accessing and
controlling JES resources. Although we chose REXX as the language for our
installation, you might choose other languages, such as C, COBOL, or
assembler.

 
 Lizette
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Elardus Engelbrecht
> > Sent: Thursday, January 05, 2017 1:50 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: IEC141I 013-A8: how to read VS data sets?
> >
> > Jesse 1 Robinson wrote:
> >
> > >Most standard utilities fail when opened to V(B)S records.
> >
> > Please name them. Just so I can shock my amazed users when they
> > complain about reading VBS things...
> >
> >
> > >Only IFASMFDP can read SMF data, and the output from that is ordinary VB.
> >
> > Really? What about DFSORT and its friend ICETOOL? (S about
> > RACF Report Writer, because that thing is 'functionally stabilized' some
> centuries ago...
> > )
> >
> > I posted a ICETOOL JCL example in IBM-MAIN which reads raw SMF data type 89.
> >
> > Also look at thread 'Re: DFSORT - ICETOOL - Search for text and
> > replace with date' in Sept 2016 where I wrote that ICETOOL can read in raw
> SMF data.
> >
> > You can write any program reading VBS data. I wrote in IBM-MAIN about
> > analysing SMF 30 using a home grown Assembler program.
> >
> > Oh, zSecure can do that trick too and do that *fast*.
> >
> >
> > >SAPI should be able to handle any spool data set.
> >
> > Yip! This is where SAPI is useful!
> >
> >
> > >OTOH I've never coded anything for SAPI; we use VPS (Levi, Ray,
> > >Shoup) to
> > extract spool data and ship it to network printers.
> >
> > That is if you give VPS ALTER access to the spool contents. I don't
> > like it, but ...
> >
> >
> > >Likewise, SDSF or equivalent ISV product can handle spool data sets
> > >whether
> > created as V or F.
> >
> > As long you re-assemble exits for third party products to read the
> > spool data using the latest JES2 macros. For SDSF or other IBM spool
> > reading products like SMTP or cs-smtp, everything is ready for reading JES2
> spool.
> >
> >
> > >SDSF now has a Rexx interface that makes it very usable for
> > >processing spool
> > files.
> >
> > Hmmm, something for me to RTFM, it may comes in handy for some
> > nefarious spool grabbing... ;-D
> >
> >
> > >FWIW it was once possible to utilize JES2 interfaces to read spool
> > >data sets
> > directly. That ability evaporated a long, long time ago.
> >
> > Oh, yes. TSPRINT (now OMCPRINT) could do that. These JES2 changes gave
> > some third party vendors real grey hairs while trying to comply to new
> > JES2 interfaces and macros. For that, I'm gratefully glad I'm not part of
> "them"...
> > ;-)
> >
> > 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

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Jesse 1 Robinson]

We’re drifting a bit here, but I had to look up ++VER to see whether a single 
PTF could be installed on more than base FMID. I find 

'-FMID--(--sysmod_id--)-'

I have never made peace with railroad track diagrams, but I think this means 
that only one base FMID can be specified. I don't see recursion. (Hate RR.)   

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Thursday, January 05, 2017 10:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
catastrophic error

On Thu, 5 Jan 2017 11:26:51 -0600, Art Gutowski wrote:

>... it probably wouldn't hurt to do a REPORT SYSMODS <1.13 zone>
>COMPAREDTO(<2.2 zone>) and vice versa.

Is that going to give you any useful information, Art? I believe that it is 
possible to code the ++VER in a PTF so that the same PTF can be applied to two 
different FMIDs, but I can't remember ever seeing it.

Of course, I have been wrong before...

--
Tom Marchant


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

Re: IEC141I 013-A8: how to read VS data sets?

[Lizette Koehler]

 http://www.redbooks.ibm.com/abstracts/sg247419.html 
  SDSF REXX Redbook

Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Elardus Engelbrecht
> Sent: Thursday, January 05, 2017 1:50 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IEC141I 013-A8: how to read VS data sets?
> 
> Jesse 1 Robinson wrote:
> 
> >Most standard utilities fail when opened to V(B)S records.
> 
> Please name them. Just so I can shock my amazed users when they complain about
> reading VBS things...
> 
> 
> >Only IFASMFDP can read SMF data, and the output from that is ordinary VB.
> 
> Really? What about DFSORT and its friend ICETOOL? (S about RACF Report
> Writer, because that thing is 'functionally stabilized' some centuries ago...
> )
> 
> I posted a ICETOOL JCL example in IBM-MAIN which reads raw SMF data type 89.
> 
> Also look at thread 'Re: DFSORT - ICETOOL - Search for text and replace with
> date' in Sept 2016 where I wrote that ICETOOL can read in raw SMF data.
> 
> You can write any program reading VBS data. I wrote in IBM-MAIN about
> analysing SMF 30 using a home grown Assembler program.
> 
> Oh, zSecure can do that trick too and do that *fast*.
> 
> 
> >SAPI should be able to handle any spool data set.
> 
> Yip! This is where SAPI is useful!
> 
> 
> >OTOH I've never coded anything for SAPI; we use VPS (Levi, Ray, Shoup) to
> extract spool data and ship it to network printers.
> 
> That is if you give VPS ALTER access to the spool contents. I don't like it,
> but ...
> 
> 
> >Likewise, SDSF or equivalent ISV product can handle spool data sets whether
> created as V or F.
> 
> As long you re-assemble exits for third party products to read the spool data
> using the latest JES2 macros. For SDSF or other IBM spool reading products
> like SMTP or cs-smtp, everything is ready for reading JES2 spool.
> 
> 
> >SDSF now has a Rexx interface that makes it very usable for processing spool
> files.
> 
> Hmmm, something for me to RTFM, it may comes in handy for some nefarious spool
> grabbing... ;-D
> 
> 
> >FWIW it was once possible to utilize JES2 interfaces to read spool data sets
> directly. That ability evaporated a long, long time ago.
> 
> Oh, yes. TSPRINT (now OMCPRINT) could do that. These JES2 changes gave some
> third party vendors real grey hairs while trying to comply to new JES2
> interfaces and macros. For that, I'm gratefully glad I'm not part of "them"...
> ;-)
> 
> 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

Re: IEC141I 013-A8: how to read VS data sets?

[Jesse 1 Robinson]

OK, I overstated my case. Did not think about SORT. Certainly ISPF cannot 
handle VBS. 

I've long operated on the ROT that you can't do much with SMF data until 
'something' converts it to VB, so I have not actually tried standards like 
IEBGENER or IDCAMS in many a moon. I am curious though as to why 'amazed users' 
would be interested in VBS data at all. Gil says that FORTRAN can handle VBS. I 
have never stared down a FORTRAN program in my career; not a likely denizen in 
business environments.

If a JES2 output segment is created with 'VS' attributes, that does not mean 
that the data on spool actually consists of spanned records. The point of 
spanning is to manage records that can exceed physical block size, e.g. 32760. 
SMF can potentially do that because so many records can have unlimited 
segments. What does physical block size even mean to JES? 

IIRC the progenitor of modern SDSF--the Interactive Spool Facility (ISF: get 
it?)--read data directly from spool using the available JES2 interface(s) that 
eventually disappeared. So did early versions of the venerable QUEUE command. 
Now SAPI is a fully defined, fully supported API. The SDSF/Rexx interface can 
be used to write output directly to a data set just as interactive XDC does. No 
additional programming required. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Thursday, January 05, 2017 12:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IEC141I 013-A8: how to read VS data sets?

Jesse 1 Robinson wrote:

>Most standard utilities fail when opened to V(B)S records.

Please name them. Just so I can shock my amazed users when they complain about 
reading VBS things...


>Only IFASMFDP can read SMF data, and the output from that is ordinary VB.  

Really? What about DFSORT and its friend ICETOOL? (S about RACF Report 
Writer, because that thing is 'functionally stabilized' some centuries ago... )

I posted a ICETOOL JCL example in IBM-MAIN which reads raw SMF data type 89.

Also look at thread 'Re: DFSORT - ICETOOL - Search for text and replace with 
date' in Sept 2016 where I wrote that ICETOOL can read in raw SMF data.

You can write any program reading VBS data. I wrote in IBM-MAIN about analysing 
SMF 30 using a home grown Assembler program.

Oh, zSecure can do that trick too and do that *fast*.


>SAPI should be able to handle any spool data set. 

Yip! This is where SAPI is useful!


>OTOH I've never coded anything for SAPI; we use VPS (Levi, Ray, Shoup) to 
>extract spool data and ship it to network printers.

That is if you give VPS ALTER access to the spool contents. I don't like it, 
but ...


>Likewise, SDSF or equivalent ISV product can handle spool data sets whether 
>created as V or F. 

As long you re-assemble exits for third party products to read the spool data 
using the latest JES2 macros. For SDSF or other IBM spool reading products like 
SMTP or cs-smtp, everything is ready for reading JES2 spool.


>SDSF now has a Rexx interface that makes it very usable for processing spool 
>files.  

Hmmm, something for me to RTFM, it may comes in handy for some nefarious spool 
grabbing... ;-D

 
>FWIW it was once possible to utilize JES2 interfaces to read spool data sets 
>directly. That ability evaporated a long, long time ago.  

Oh, yes. TSPRINT (now OMCPRINT) could do that. These JES2 changes gave some 
third party vendors real grey hairs while trying to comply to new JES2 
interfaces and macros. For that, I'm gratefully glad I'm not part of "them"... 
;-)

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

Re: IEC141I 013-A8: how to read VS data sets?

[Elardus Engelbrecht]

Jesse 1 Robinson wrote:

>Most standard utilities fail when opened to V(B)S records.

Please name them. Just so I can shock my amazed users when they complain about 
reading VBS things...


>Only IFASMFDP can read SMF data, and the output from that is ordinary VB.  

Really? What about DFSORT and its friend ICETOOL? (S about RACF Report 
Writer, because that thing is 'functionally stabilized' some centuries ago... )

I posted a ICETOOL JCL example in IBM-MAIN which reads raw SMF data type 89.

Also look at thread 'Re: DFSORT - ICETOOL - Search for text and replace with 
date' in Sept 2016 where I wrote that ICETOOL can read in raw SMF data.

You can write any program reading VBS data. I wrote in IBM-MAIN about analysing 
SMF 30 using a home grown Assembler program.

Oh, zSecure can do that trick too and do that *fast*.


>SAPI should be able to handle any spool data set. 

Yip! This is where SAPI is useful!


>OTOH I've never coded anything for SAPI; we use VPS (Levi, Ray, Shoup) to 
>extract spool data and ship it to network printers.

That is if you give VPS ALTER access to the spool contents. I don't like it, 
but ...


>Likewise, SDSF or equivalent ISV product can handle spool data sets whether 
>created as V or F. 

As long you re-assemble exits for third party products to read the spool data 
using the latest JES2 macros. For SDSF or other IBM spool reading products like 
SMTP or cs-smtp, everything is ready for reading JES2 spool.


>SDSF now has a Rexx interface that makes it very usable for processing spool 
>files.  

Hmmm, something for me to RTFM, it may comes in handy for some nefarious spool 
grabbing... ;-D

 
>FWIW it was once possible to utilize JES2 interfaces to read spool data sets 
>directly. That ability evaporated a long, long time ago.  

Oh, yes. TSPRINT (now OMCPRINT) could do that. These JES2 changes gave some 
third party vendors real grey hairs while trying to comply to new JES2 
interfaces and macros. For that, I'm gratefully glad I'm not part of "them"... 
;-)

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

Re: IEC141I 013-A8: how to read VS data sets?

[Paul Gilmartin]

On Thu, 5 Jan 2017 13:50:25 -0500, Carmen Vitullo wrote:

>for my own sake I checked some sysout of my own and if you scroll over to the 
>right in the jes2 dataset view from ? you see jes2 dataset attributes, I see 
>RECFM V and U and VA and UA, no VS for any jes2 datasets 
> 
Ah, but did you allocate one?  When I do that BPXWDYN(), I see:

 SDSF JOB DATA SET DISPLAY - JOB LONGOUT5 (JOB05373)
 COMMAND INPUT ===>
 NP   DDNAME   StepName RecFM LRecL
  JESMSGLG JES2 UA  133
  JESJCL   JES2 V   132
  JESYSMSG JES2 VA  133
  SYSTSPRT SETUPVBA 133
  TESTO1   SETUPVBS   32748 

Experimenting further, JCL seems to impose a limit of LRECL=32761;
ISPF and BPXWDYN a limit of LRECL=32760.  I see no rationale for either of
those numbers -- the only one that would make sense is 32767, the max
signed halfword value.  Allocating with ISPF assigns halftrack BLKSIZE;
no information for JCL because I never wrote to it.

And when BPXWDYN successfully allocates with LRECL=32750, ISPF
Data Set Utility reports LRECL=32756.

>- Original Message -
>From: "Jesse 1 Robinson"
>Sent: Thursday, January 5, 2017 12:40:16 PM 
>Subject: Re: IEC141I 013-A8: how to read VS data sets? 
>
>Like Walt, I'm skeptical of the assertion that a spool data set is VS, where 
>'S' means 'spanned'. Spanned records are extremely rare in MVS. The only use 
>for them I've ever come across is MANx SMF, which I believe predates dirt. 
>Most standard utilities fail when opened to V(B)S records. Only IFASMFDP can 
>read SMF data, and the output from that is ordinary VB. 
>
I've been told that VBS was invented to support FORTRAN, so that FORTRAN
programs could move from tape to DASD.

And, for whatever reason, Rexx EXECIO has very lately been granted capability
for RECFM=VBS (and for RECFM=U).

--gil

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

Re: CLOCKxx - ACCURACY Parameter - IEA032E message

[George Kozakos]

> It would seem to me, that for the accuracy keyword to work, that STP
> must be using external time sources directly?  Or is ACCURACY only
> really reporting on clock steering events > 50 milliseconds(in your
case)?

ACCURACY is looking at the steering information and issuing IEA032E if the
steering adjustment is greater than the ACCURACY threshold. The steering
information used is identical to the information seen via the STP
"Adjustment Steering Information" panel accessed via the "Timing Network"
panel
>
> I ask, because we had an event several months back, where our
> Firewall team botched up the rules, and all of our HMC's lost
> internet access to NIST, and even though the boxes phoned home to
> IBM, our own internal problem notifications procedures broke down,
> and time was allowed to drift for over a week.  In our case, STP was
> fat, dumb, and happy because he was communicating nicely with his
> NTP servers(multiple HMCs), and it was the HMC's that were falling
> out of accuracy.   So, I don’t know if this would help me or not.

Right, the ACCURACY keyword would not have helped in that scenario.

Regards, George Kozakos
z/OS Software Service, Level 2 Supervisor


IBM Mainframe Discussion List  wrote on
04/01/2017 07:54:19 AM:

> From: "Jousma, David" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 04/01/2017 07:54 AM
> Subject: Re: CLOCKxx - ACCURACY Parameter - IEA032E message
> Sent by: IBM Mainframe Discussion List 
>
> Glenn,
>
> I wasn’t even familiar with this keyword until you brought it up.
> However, a couple of comments.   In our shop, we have the HMC's
> acting as NTP clients to external NIST servers for time updates, and
> as NTP servers for STP, and the mainframe as NTP server for the rest
> of the datacenter.   Our HMC's have firewall rules configured to
> allow outbound connections to be able to reach NIST.  I realize we
> could have configured STP to go to NIST directly for time updates,
> but we didn’t want to expose the SE's (even via firewall) to the
> internet for time updates directly.
>
> It would seem to me, that for the accuracy keyword to work, that STP
> must be using external time sources directly?  Or is ACCURACY only
> really reporting on clock steering events > 50 milliseconds(in your
case)?
>
> I ask, because we had an event several months back, where our
> Firewall team botched up the rules, and all of our HMC's lost
> internet access to NIST, and even though the boxes phoned home to
> IBM, our own internal problem notifications procedures broke down,
> and time was allowed to drift for over a week.  In our case, STP was
> fat, dumb, and happy because he was communicating nicely with his
> NTP servers(multiple HMCs), and it was the HMC's that were falling
> out of accuracy.   So, I don’t know if this would help me or not.
>
> _
> Dave Jousma
> Manager Mainframe Engineering, Assistant Vice President
> david.jou...@53.com
> 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
> p 616.653.8429
> f 616.653.2717
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU
> ] On Behalf Of Glenn Miller
> Sent: Tuesday, January 03, 2017 5:46 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: CLOCKxx - ACCURACY Parameter - IEA032E message
>
> A few months ago we activated the "ACCURACY" parameter with a value
> of 50 ( the default is zero ) on a few of our z/OS systems ( all
> systems are z/OS V2R1 ).  We verified that the "IEA034I THE TOD
> CLOCK ACCURACY MONITOR IS ACTIVE." is issued whenever these z/OS
> systems are IPL'ed.
> Until Saturday night, we have never received any "alert" from this
> TOD CLOCK ACCURACY MONITOR.  However, we did receive the following
> message on each z/OS system that has that monitor active:
> IEA032E TOD CLOCK ACCURACY LIMITS MAY HAVE BEEN EXCEEDED.
>
> The IEA032E messages occurred around 8PM Eastern Time on December
> 31, 2016. The IEA032E messages were repeated every hour on each z/OS
> system until about 2AM on January 1, 2017, or about 6 hours after
> they started.  Also, the IEA032E messages have not re-occurred since
> that 2AM timeframe.
>
> We have confirmation from IBM that the IEA032E messages were
> triggered by the leap second that was inserted into UTC. They also
> indicated how to perform a leap second adjustment via the STP panels
> if we needed the 50ms accuracy when the leap second occurred.
>
>
> Has anyone else implemented the TOD accuracy monitor on their z/OS
> systems?  Did anyone else receive the IEA032E messages or did you
> perform the leap second adjustment ahead of the leap second occurrence?
>
> Glenn Miller
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> This e-mail transmission 

Re: IEC141I 013-A8: how to read VS data sets?

[Carmen Vitullo]

for my own sake I checked some sysout of my own and if you scroll over to the 
right in the jes2 dataset view from ? you see jes2 dataset attributes, I see 
RECFM V and U and VA and UA, no VS for any jes2 datasets 
Carmen 

- Original Message -

From: "Jesse 1 Robinson"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, January 5, 2017 12:40:16 PM 
Subject: Re: IEC141I 013-A8: how to read VS data sets? 

Like Walt, I'm skeptical of the assertion that a spool data set is VS, where 
'S' means 'spanned'. Spanned records are extremely rare in MVS. The only use 
for them I've ever come across is MANx SMF, which I believe predates dirt. Most 
standard utilities fail when opened to V(B)S records. Only IFASMFDP can read 
SMF data, and the output from that is ordinary VB. 

SAPI should be able to handle any spool data set. OTOH I've never coded 
anything for SAPI; we use VPS (Levi, Ray, Shoup) to extract spool data and ship 
it to network printers. Likewise, SDSF or equivalent ISV product can handle 
spool data sets whether created as V or F. SDSF now has a Rexx interface that 
makes it very usable for processing spool files. 

FWIW it was once possible to utilize JES2 interfaces to read spool data sets 
directly. That ability evaporated a long, long time ago. 

. 
. 
J.O.Skip Robinson 
Southern California Edison Company 
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager 
323-715-0595 Mobile 
626-543-6132 Office ⇐=== NEW 
robin...@sce.com 


-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Walt Farrell 
Sent: Thursday, January 05, 2017 8:54 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: (External):Re: IEC141I 013-A8: how to read VS data sets? 

On Thu, 5 Jan 2017 21:13:48 +0700, Robin Atwood  wrote: 

>The JCL is not relevant, both applications are servers that use dynamic 
>allocation. They are using SAPI to read the JES spool. The >message is 
> 
>IEC141I 013-A8,IGG0199G,TAURISP3,TAURISP3,SYS2 
> 
>The spool data set is allocated to SYS2. I am really interested in advice 
>about reading VS data sets, what access method to use, >etc. 

What makes you think the data on spool is VS in format? That seems to me to be 
an unusual record format for someone to use writing spool data. Perhaps the 
error is that the program issuing the OPEN to try to read it is saying RECFM=VS 
when it's really just V? 

(Note, too, that there are two other potential program errors: specifying 
RECFM=D, or specifying both ANSI and Machine control characters. But all of 
these really seem to indicate an error in the program, and I'd say that the 
program author needs to examine the dump and figure it out.) 

-- 
Walt 


-- 
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: IEC141I 013-A8: how to read VS data sets?

[Jesse 1 Robinson]

Like Walt, I'm skeptical of the assertion that a spool data set is VS, where 
'S' means 'spanned'. Spanned records are extremely rare in MVS. The only use 
for them I've ever come across is MANx SMF, which I believe predates dirt. Most 
standard utilities fail when opened to V(B)S records. Only IFASMFDP can read 
SMF data, and the output from that is ordinary VB. 

SAPI should be able to handle any spool data set. OTOH I've never coded 
anything for SAPI; we use VPS (Levi, Ray, Shoup) to extract spool data and ship 
it to network printers. Likewise, SDSF or equivalent ISV product can handle 
spool data sets whether created as V or F. SDSF now has a Rexx interface that 
makes it very usable for processing spool files. 

FWIW it was once possible to utilize JES2 interfaces to read spool data sets 
directly. That ability evaporated a long, long time ago. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Walt Farrell
Sent: Thursday, January 05, 2017 8:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IEC141I 013-A8: how to read VS data sets?

On Thu, 5 Jan 2017 21:13:48 +0700, Robin Atwood  wrote:

>The JCL is not relevant, both applications are servers that use dynamic 
>allocation. They are using SAPI to read the JES spool. The >message is
>
>IEC141I 013-A8,IGG0199G,TAURISP3,TAURISP3,SYS2
>
>The spool data set is allocated to SYS2. I am really interested in advice 
>about reading VS data sets, what access method to use, >etc.

What makes you think the data on spool is VS in format? That seems to me to be 
an unusual record format for someone to use writing spool data. Perhaps the 
error is that the program issuing the OPEN to try to read it is saying RECFM=VS 
when it's really just V?

(Note, too, that there are two other potential program errors: specifying 
RECFM=D, or specifying both ANSI and Machine control characters. But all of 
these really seem to indicate an error in the program, and I'd say that the 
program author needs to examine the dump and figure it out.)

--
Walt


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

Re: Addressing Question

[scott Ford]

All,

My intent was clarification for my old age. I went back and looked and I am
good.

Thanks all..

Scott

On Thu, Jan 5, 2017 at 10:24 AM scott Ford  wrote:

> Tom,
>
> Thx for you comment. I agree otherwise there is confusion.
>
>
> Scott
>
> On Thu, Jan 5, 2017 at 4:55 AM Tom Marchant <
> 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
>
> On Wed, 4 Jan 2017 16:24:12 -0600, Bill Woodger wrote:
>
>
>
> >No. Your CALLs are static.
>
> >
>
>
>
> Bill,
>
>
>
> It would be helpful if you would quote enough of the message that you
>
> are replying to to provide context to what your "No" references.
>
>
>
> --
>
> Tom Marchant
>
>
>
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> Scott Ford
> IDMWORKS
> z/OS Development
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: Addressing Question

[scott Ford]

Tom,

Thx for you comment. I agree otherwise there is confusion.


Scott

On Thu, Jan 5, 2017 at 4:55 AM Tom Marchant <
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 4 Jan 2017 16:24:12 -0600, Bill Woodger wrote:
>
>
>
> >No. Your CALLs are static.
>
> >
>
>
>
> Bill,
>
>
>
> It would be helpful if you would quote enough of the message that you
>
> are replying to to provide context to what your "No" references.
>
>
>
> --
>
> Tom Marchant
>
>
>
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
Scott Ford
IDMWORKS
z/OS Development

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

Re: UTC and Daylight Savings Time

[Jesse 1 Robinson]

I have not seen anyone mention LPAR time offset. It's been around for 
years--around Y2K IIRC--but we've never had a need to use it. In the LPAR Image 
profile, you have this option:

Clock Type Assignment
  Standard time of day 
  Logical partition time offset

If you select Standard, the LPAR will take UTC and local directly from the 
external time source, once Sysplex Timer, now STP.

If you select Logical, you can run each LPAR at its own local offset. I believe 
(cannot prove) that the LPAR is still synchronized with the external timer, but 
local time is calculated according to your own LPAR definition. I certainly 
have no idea how this works without an external timer, but I suggest you 
explore the option. Your situation is exactly why the option was created.

Changing your configuration to run with true UTC is not transparent. When we 
did it, the DB2 folks in particular had to interpret their logs differently. 
This was about two decades ago; life has gone on. Meanwhile, with modern 
software in place, it is no longer necessary to restart DB2, CICS, or any other 
time-sensitive task.  

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, January 05, 2017 9:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: UTC and Daylight Savings Time

On Thu, 5 Jan 2017 17:02:23 +, Bill Bishop (TMNA) wrote:

>I have been requested to investigate the impact of switching "local" time to 
>"UTC" time.
>
>We currently use STP to establish the time and offsets for our LPARs, so 
>basically we are using UTC time correctly.
>
>However, the requirement may include not changing local time when daylight 
>savings time occurs.  The intent is to maintain a consistent 'displayed' time 
>world-wide as many places do not adjust times.
> 
If your operations are worldwide, UTC would seem the sensible choice.

>Using STP, the local time changes automatically and I am not aware of any way 
>prevent it.  
> 
Surely STP can accomadate locales even in the U.S. such as Arizoa and Hawaii 
which do not observe Daylight Saving time, more so oveseas and in the southern 
hemisphere.

>Is anyone aware of how to accomplish this?

-- gil


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

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Tom Marchant]

On Thu, 5 Jan 2017 11:26:51 -0600, Art Gutowski wrote:

>... it probably wouldn't hurt to do a REPORT SYSMODS <1.13 zone> 
>COMPAREDTO(<2.2 zone>) and vice versa.

Is that going to give you any useful information, Art? I believe that it is 
possible to code the ++VER in a PTF so that the same PTF can be applied 
to two different FMIDs, but I can't remember ever seeing it.

Of course, I have been wrong before...

-- 
Tom Marchant

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

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Pommier, Rex]

Hi Allan,

Thanks for your response.  Here's where I am in regards to them.

1)  I need to double check compatibility maintenance.  The only initialization 
parameters listed in the migration guide as needing changes are optional 
(removing BROADCAST from OUTDEF and JCLERR from JOBDEF) and I did that.  The 
incompatibilities associated with z2 versus z11 versus z22 mode all point to 
the fact that I'm running z11 mode.  These are the SPOOLDEF LARGEDS=ALLOWED.  
If I do a $D CKPTSPACE,BERTUSE shows I am using about 500 BERTs and have over 
17,000 free.  

2)  $BR1 in M gives me "lots" of good information .  The doc says "JES2 
initialization processing encountered an error examining the BERT maps" and the 
resolution is " Use the indicative dump and the SVC dump (if any) to diagnose 
the error.".  

3)  That'll be happening probably today.  

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Allan Staller
Sent: Thursday, January 05, 2017 7:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error

I believe z/OS 2.2 fits within the N-2 compat/fallback range so:

1) verify all compat/fallback maint is installed on the 1.13 system. Check for 
incompatable initialization parameters in the 2.2 JESPARMS.
2) look up $BR1 in JES messages/codes to see if any insight can be gained there 
3)Contact IBM for assistance...

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pommier, Rex
Sent: Wednesday, January 4, 2017 9:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error

Hello list,

Upgrading from z/OS 1.13 to 2.2.  Attempted to IPL it tonight in our sandbox 
using a clone of one of our production LPARs.  Tried to bring JES2 up warm and 
got a $HASP095 catastrophic error code=$BR1.  We are running z11 mode on 1.13 
and the $HASP493 warm start message verified z11 mode.  I got a system dump of 
JES2 when it failed and will attempt to figure out something in it tomorrow, 
but was wondering if anybody has seen anything like this.  I restarted JES2 
bringing it up COLD and it came right up, in z22 mode.

Does anybody know offhand if JES2 needs to be brought up cold when migrating 
from 1.13 to 2.2 or what might be the problem.  I didn't quiesce JES2 on the 
current 1.13 system before creating the clone for the sandbox, but we've not 
had issues with doing this before for DR testing (not moving to a new release).

Any thoughts/ideas would be most welcome.

TIA,

Rex


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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


::DISCLAIMER::


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



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

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Art Gutowski]

From "Pommier, Rex"  on Thu, 5 Jan 2017 17:17:01 +:

>Thanks for the suggestion.  We are already running MODE=DUPLEX.

We had one or two systems where we had to make this change, and a couple that 
we had to migrate to z11 checkpoint format.  Other than that, no issues with 
upgrade and downgrade via WARMSTART between 1.13 and 2.2.

As others suggested, verify your toleration maintenance, and it probably 
wouldn't hurt to do a REPORT SYSMODS <1.13 zone> COMPAREDTO(<2.2 zone>) and 
vice versa.  I've been burned by "missing" PTFs before that make incompatible 
changes (e.g., previously mentioned incompatible parameters, though these 
usually are resolved via startup prompts).

Finally, do you have any exits installed?  We had to rewrite a few of our exits 
for 2.2.  I don't know which (I'm not on the upgrade project), but I can find 
out.

Regards,
Art Gutowski
General Motors, LLC

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

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Pommier, Rex]

Hi Ravi,

Thanks for the suggestion.  We are already running MODE=DUPLEX.


CKPTDEF  CKPT1=(DSNAME=SYS1.HASPCKPA,
 VOLSER=Z1PG02,  
 INUSE=YES), 
 CKPT2=(DSNAME=SYS1.HASPCKPB,
 VOLSER=Z1PG03,  
 INUSE=YES), 
 DUPLEX=ON,  
 LOGSIZE=2,  
 MODE=DUPLEX,
 VERSIONS=(NUMBER=0, 
WARN=80),
 VOLATILE=(ONECKPT=WTOR, 
ALLCKPT=WTOR)

Rex



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ravi Gaur
Sent: Thursday, January 05, 2017 7:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error

Also not to miss if you have MODE=DUAL have it changed to MODE=DUPLEX  
...There's an APAR regarding it with zOS2.2

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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

Re: UTC and Daylight Savings Time

[Paul Gilmartin]

On Thu, 5 Jan 2017 17:02:23 +, Bill Bishop (TMNA) wrote:

>I have been requested to investigate the impact of switching "local" time to 
>"UTC" time.
>
>We currently use STP to establish the time and offsets for our LPARs, so 
>basically we are using UTC time correctly.
>
>However, the requirement may include not changing local time when daylight 
>savings time occurs.  The intent is to maintain a consistent 'displayed' time 
>world-wide as many places do not adjust times.
> 
If your operations are worldwide, UTC would seem the sensible choice.

>Using STP, the local time changes automatically and I am not aware of any way 
>prevent it.  
> 
Surely STP can accomadate locales even in the U.S. such as Arizoa and Hawaii 
which do
not observe Daylight Saving time, more so oveseas and in the southern 
hemisphere.

>Is anyone aware of how to accomplish this?

-- gil

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

Re: UTC and Daylight Savings Time

[Roger W Suhr]

Local time is just that, local - which means the time must adhere to the LOCAL 
requirement. UTC is the world wide standard time, it will not change for 
daylight savings.


Sent from my Verizon, Samsung Galaxy smartphone
 Original message From: "Bill Bishop (TMNA)" 
 Date: 1/5/17  11:02  (GMT-06:00) To: 
IBM-MAIN@LISTSERV.UA.EDU Subject: UTC and Daylight Savings Time 
I have been requested to investigate the impact of switching "local" time to 
"UTC" time.

We currently use STP to establish the time and offsets for our LPARs, so 
basically we are using UTC time correctly.

However, the requirement may include not changing local time when daylight 
savings time occurs.  The intent is to maintain a consistent 'displayed' time 
world-wide as many places do not adjust times.

Using STP, the local time changes automatically and I am not aware of any way 
prevent it.  

Is anyone aware of how to accomplish this?

Thanks

Bill Bishop
Consultant, Mainframe Engineer
Mainframe and Scheduling - Infrastructure Technology Services Toyota Motor 
North America

--
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: UTC and Daylight Savings Time

[Nims,Alva John (Al)]

What is your CLOCK00 entries in SYS1.PARMLIB like?

I think if you code:
STPZONE NO 
&
TIMEZONE W 00.00.00

You would be running UTC and not be affected by DST & Time Zones

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Bishop (TMNA)
Sent: Thursday, January 05, 2017 12:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: UTC and Daylight Savings Time

I have been requested to investigate the impact of switching "local" time to 
"UTC" time.

We currently use STP to establish the time and offsets for our LPARs, so 
basically we are using UTC time correctly.

However, the requirement may include not changing local time when daylight 
savings time occurs.  The intent is to maintain a consistent 'displayed' time 
world-wide as many places do not adjust times.

Using STP, the local time changes automatically and I am not aware of any way 
prevent it.  

Is anyone aware of how to accomplish this?

Thanks

Bill Bishop
Consultant, Mainframe Engineer
Mainframe and Scheduling - Infrastructure Technology Services Toyota Motor 
North America

--
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: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Pommier, Rex]

Hi Elardus,

  What do you see if you issue $D ACTIVATE during that 
disastrous IPL?

I couldn't do a $D ACTIVATE because JES was down.  Once it came up cold, it 
shows that I'm in Z22 mode.

  This is documented and WAD, but very very disruptive!

Yup, and not something I want to do.  There is documented a way around this, 
where you can bring JES up cold in Z11 mode, that is to put in the OPTSDEF 
JES2PARM COLD_START_MODE=Z11.  That allows compatibility to older JES releases 
but doesn't fix the problem of needing a cold start.

The only migration action required going from 1.13 to 2.2 is to be a1 z11 mode 
which we are.  Output from a $D ACTIVATE on my 1.13 system shows:

$HASP895 $DACTIVATE 751
$HASP895 JES2 CHECKPOINT MODE IS CURRENTLY Z11 
$HASP895 THE CURRENT CHECKPOINT:   
$HASP895  -- CONTAINS 18100 BERTS AND BERT UTILIZATION IS 2
$HASP895 PERCENT.  
$HASP895  -- CONTAINS 1283 4K RECORDS. 


Rex


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Thursday, January 05, 2017 1:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error

Pommier, Rex wrote:

>Upgrading from z/OS 1.13 to 2.2.  Attempted to IPL it tonight in our 
>sandbox using a clone of one of our production LPARs.  Tried to bring 
>JES2 up warm and got a $HASP095 catastrophic error code=$BR1.  We are 
>running z11 mode on 1.13 and the $HASP493 warm start message verified 
>z11 mode.  I got a system dump of JES2 when it failed and will attempt 
>to figure out
something in it tomorrow, but was wondering if anybody has seen anything like 
this. 

What do you see if you issue $D ACTIVATE during that disastrous IPL?


> I restarted JES2 bringing it up COLD and it came right up, in z22 mode.

This is documented and WAD, but very very disruptive!


>Does anybody know offhand if JES2 needs to be brought up cold when migrating 
>from 1.13 to 2.2 or what might be the problem.  

I have RTFM, but could not find any such requirements, unless I missed 
something.


>I didn't quiesce JES2 on the current 1.13 system before creating the clone for 
>the sandbox, but we've not had issues with doing this before for DR testing 
>(not moving to a new release).

>Any thoughts/ideas would be most welcome.

Check Health Checker - JES2_UPGRADE_CKPT_LEVEL_JES2

Also check OA48823 (about $IV8, not about your $BR1) and similar APARs. There 
are a few of them for JES2.

I believe I have seen discussions about this (upgrade and toleration of JES2) 
previously.

You should check out the migration actions needed all the way from z/OS v1.13 
to v2.2 for JES2.

PS: we are not at 2.2 at all, because we are still dragging a 1.13 LPAR... 
don't ask. ;-)

Good luck!

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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

UTC and Daylight Savings Time

[Bill Bishop (TMNA)]

I have been requested to investigate the impact of switching "local" time to 
"UTC" time.

We currently use STP to establish the time and offsets for our LPARs, so 
basically we are using UTC time correctly.

However, the requirement may include not changing local time when daylight 
savings time occurs.  The intent is to maintain a consistent 'displayed' time 
world-wide as many places do not adjust times.

Using STP, the local time changes automatically and I am not aware of any way 
prevent it.  

Is anyone aware of how to accomplish this?

Thanks

Bill Bishop
Consultant, Mainframe Engineer
Mainframe and Scheduling - Infrastructure Technology Services Toyota Motor 
North America

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

Re: IEC141I 013-A8: how to read VS data sets?

[Walt Farrell]

On Thu, 5 Jan 2017 21:13:48 +0700, Robin Atwood  wrote:

>The JCL is not relevant, both applications are servers that use dynamic 
>allocation. They are using SAPI to read the JES spool. The >message is
>
>IEC141I 013-A8,IGG0199G,TAURISP3,TAURISP3,SYS2
>
>The spool data set is allocated to SYS2. I am really interested in advice 
>about reading VS data sets, what access method to use, >etc.

What makes you think the data on spool is VS in format? That seems to me to be 
an unusual record format for someone to use writing spool data. Perhaps the 
error is that the program issuing the OPEN to try to read it is saying RECFM=VS 
when it's really just V?

(Note, too, that there are two other potential program errors: specifying 
RECFM=D, or specifying both ANSI and Machine control characters. But all of 
these really seem to indicate an error in the program, and I'd say that the 
program author needs to examine the dump and figure it out.)

-- 
Walt

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

Re: IEC141I 013-A8: how to read VS data sets?

[Lizette Koehler]

Is this homegrown or vendor product like Mobius, VPS or other like product?

There is no obvious reason, short of reading a dump, to know what one job works 
and one job does not.

If vendor product, then I would contact the vendor.

Otherwise I would contact IBM - probably JES2

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Robin Atwood
> Sent: Thursday, January 05, 2017 7:14 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IEC141I 013-A8: how to read VS data sets?
> 
> The JCL is not relevant, both applications are servers that use dynamic
> allocation. They are using SAPI to read the JES spool. The message is
> 
> IEC141I 013-A8,IGG0199G,TAURISP3,TAURISP3,SYS2
> 
> The spool data set is allocated to SYS2. I am really interested in advice
> about reading VS data sets, what access method to use, etc.
> 
> Thanks
> Robin
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: 05 January 2017 19:47
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IEC141I 013-A8: how to read VS data sets?
> 
> Robin,
> Please delete any part of the email you did a REPLY to that does not pertain
> to your question.  It tends to confuse the issue.
> 
> Next, I am not clear on Reading a VS on JES2 Spool.  JES2 Spool has its own
> unique process for creating SYSOUT.  So if you could explain further that
> could help.
> 
> If you are asking about a job that abended when trying to Read a VS dataset
> and got an S013-A8, then that is a different question.
> 
> When I look up your abend code
> 
> An incorrect record format was requested for a SYSIN, SYSOUT, or subsystem
> data set with BSAM or QSAM or for a z/OS UNIX directory with BPAM. One of the
> following conditions was detected:
> 
> RECFM=D was specified.
> Variable spanned records (VS or VBS) were requested for input.
> Both ANSI and machine control characters were specified.
> 
> Please show the  JCL from the job that runs good and the job that fails.  You
> can change the dataset name and I think we only need the JCL to see the way it
> is coded.
> 
> Again, you would read SYSOUT On JES2 not a VS dataset on JES2.  Unless your
> application is trying to run a JES2 SSI function to read SYSOUT.
> 
> Please provide further details.
> 
> And if you could post the complete IEC141 I message, that would also be
> helpful.  Again just change the dataset name.
> 
> Lizette
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Robin Atwood
> > Sent: Thursday, January 05, 2017 5:31 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: IEC141I 013-A8: how to read VS data sets?
> >
> > One of our apps abends if trying to read a VS data set on the JES2
> > spool. The message manual tells me this is because it is not allowed
> > to read VS SYSOUT using QSAM. Yet we have another application which does
> exactly that.
> > Furthermore, after one day of staring at the code I cannot see any
> > functional difference between the two routines:
> > both use identical DCB/DCBEs. SDSF can read the data set of course,
> > but I expect it has some internal interface. So I searched on what is
> > the correct way to read VS data sets and found virtually nothing.
> > Anybody got any experience of this?
> >
> > Thanks
> > Robin

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

Re: Delete NVR entries where ENQ shows from LLA/XCFAS

[Tom Marchant]

On Thu, 5 Jan 2017 08:01:15 -0600, John McKown wrote:

>Why not
>https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae200/remenq.htm
>?

IMO, this is better:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.idas300/rname.htm

-- 
Tom Marchant

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

Re: IEC141I 013-A8: how to read VS data sets?

[Robin Atwood]

The JCL is not relevant, both applications are servers that use dynamic 
allocation. They are using SAPI to read the JES spool. The message is

IEC141I 013-A8,IGG0199G,TAURISP3,TAURISP3,SYS2

The spool data set is allocated to SYS2. I am really interested in advice 
about reading VS data sets, what access method to use, etc.

Thanks
Robin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: 05 January 2017 19:47
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEC141I 013-A8: how to read VS data sets?

Robin,
Please delete any part of the email you did a REPLY to that does not pertain to 
your question.  It tends to confuse the issue.

Next, I am not clear on Reading a VS on JES2 Spool.  JES2 Spool has its own 
unique process for creating SYSOUT.  So if you could explain further that could 
help.

If you are asking about a job that abended when trying to Read a VS dataset and 
got an S013-A8, then that is a different question.

When I look up your abend code

An incorrect record format was requested for a SYSIN, SYSOUT, or subsystem data 
set with BSAM or QSAM or for a z/OS UNIX directory with BPAM. One of the 
following conditions was detected:

RECFM=D was specified.
Variable spanned records (VS or VBS) were requested for input.
Both ANSI and machine control characters were specified.

Please show the  JCL from the job that runs good and the job that fails.  You 
can change the dataset name and I think we only need the JCL to see the way it 
is coded.

Again, you would read SYSOUT On JES2 not a VS dataset on JES2.  Unless your 
application is trying to run a JES2 SSI function to read SYSOUT.  

Please provide further details.

And if you could post the complete IEC141 I message, that would also be 
helpful.  Again just change the dataset name.

Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Robin Atwood
> Sent: Thursday, January 05, 2017 5:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IEC141I 013-A8: how to read VS data sets?
> 
> One of our apps abends if trying to read a VS data set on the JES2 
> spool. The message manual tells me this is because it is not allowed 
> to read VS SYSOUT using QSAM. Yet we have another application which does 
> exactly that.
> Furthermore, after one day of staring at the code I cannot see any 
> functional difference between the two routines:
> both use identical DCB/DCBEs. SDSF can read the data set of course, 
> but I expect it has some internal interface. So I searched on what is 
> the correct way to read VS data sets and found virtually nothing. 
> Anybody got any experience of this?
> 
> Thanks
> Robin
> 

--
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: Delete NVR entries where ENQ shows from LLA/XCFAS

[Ravi Gaur]

These all were old/uncatalog's datasets left on the pack which were used with 
z/OS1.13 as sysres(way back we moved to 2.1 and now over to 2.2) so as had same 
name dsn got enqueue with LLA/XCFAS , now as some of you responded being simple 
was to get the init done however due to storage management policy(which I need 
to fight further ) they wanted to have them empty/scratch before init...

So obviously to bring down lla/xcfas and then delete them would have to wait 
for change...meanwhile I used inhouse bypass enqueue to get them clear

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

Re: Delete NVR entries where ENQ shows from LLA/XCFAS

[John McKown]

Why not
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae200/remenq.htm
?



On Thu, Jan 5, 2017 at 7:55 AM, Ravi Gaur  wrote:

> These all were old/uncatalog's datasets left on the pack which were used
> with z/OS1.13 as sysres(way back we moved to 2.1 and now over to 2.2) so as
> had same name dsn got enqueue with LLA/XCFAS , now as some of you responded
> being simple was to get the init done however due to storage management
> policy(which I need to fight further ) they wanted to have them
> empty/scratch before init...
>
> So obviously to bring down lla/xcfas and then delete them would have to
> wait for change...meanwhile I used inhouse bypass enqueue to get them
> clear
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
There’s no obfuscated Perl contest because it’s pointless.

—Jeff Polk

Maranatha! <><
John McKown

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

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Ravi Gaur]

Also not to miss if you have MODE=DUAL have it changed to MODE=DUPLEX  
...There's an APAR regarding it with zOS2.2

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

Re: How many FRR stack entries are available?

[Binyamin Dissen]

I am writing code that is called by the end-user in SRB mode, and the code
will issue a PC. The caller may very well have its own FRR.

I would like to have the API have an FRR as well as the PC routine. Is there
some programable way I can determine how many are free (if only 1, I would
prefer to have it at the PC level)?

On Thu, 5 Jan 2017 08:06:19 -0500 Peter Relson  wrote:

:>
:>The manual states
:>   "The system only guarantees that installations can add two FRRs"
:>Is that still true for zOS 2?
:>
:>
:>Yes it is still true. That is not a statement about how much room there is 
:>for FRRs overall in the FRR stack (which, as it has long been, is 16 
:>entries worth).
:>
:>Peter Relson
:>z/OS Core Technology Design
:>
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: Delete NVR entries where ENQ shows from LLA/XCFAS

[Tom Marchant]

On Thu, 5 Jan 2017 05:37:08 -0700, Lizette Koehler wrote:

> If these are Linklst'd datasets, then you could 
>  1) Build a new LINKLST and remove these datasets in the new LINKLST
>  2) Do what you need to with these files (move, delete)

A new LNKLST set without the data sets is not sufficient. The old LNKLST 
set will still be active, and the data set still in use. See topic "Removing or 
compressing a data set in an active LNKLST set" in the MVS Initialization 
and Tuning reference. In order to be effective, after creating and activating 
the new LNKLST set, you need to issue

LNKLST UPDATE JOB(*)

so that no active address space using the old LNKLST set.

However, be aware that doing so involves risk. Many of us have done so and 
gotten away with it, but if you are unlucky, you may have to IPL to recover 
from the errors that were caused.

-- 
Tom Marchant

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

Re: How many FRR stack entries are available?

[Elardus Engelbrecht]

Peter Relson wrote:

>>The manual states   "The system only guarantees that installations can add 
>>two FRRs"
>>Is that still true for zOS 2?
>Yes it is still true.

Thanks! I have searced around, but in what book is that written?


> That is not a statement about how much room there is for FRRs overall in the 
> FRR stack (which, as it has long been, is 16 entries worth).

I see in 'z/OS MVS Diagnosis: Reference' (z/OS v2.1) this other, but limit: 
'There is always one set of FRR stacks per processor.'

So how does it relate to what you wrote?

Just curious if you dont mind please!

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

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Allan Staller]

I believe z/OS 2.2 fits within the N-2 compat/fallback range so:

1) verify all compat/fallback maint is installed on the 1.13 system. Check for 
incompatable initialization parameters in the 2.2 JESPARMS.
2) look up $BR1 in JES messages/codes to see if any insight can be gained there
3)Contact IBM for assistance...

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pommier, Rex
Sent: Wednesday, January 4, 2017 9:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error

Hello list,

Upgrading from z/OS 1.13 to 2.2.  Attempted to IPL it tonight in our sandbox 
using a clone of one of our production LPARs.  Tried to bring JES2 up warm and 
got a $HASP095 catastrophic error code=$BR1.  We are running z11 mode on 1.13 
and the $HASP493 warm start message verified z11 mode.  I got a system dump of 
JES2 when it failed and will attempt to figure out something in it tomorrow, 
but was wondering if anybody has seen anything like this.  I restarted JES2 
bringing it up COLD and it came right up, in z22 mode.

Does anybody know offhand if JES2 needs to be brought up cold when migrating 
from 1.13 to 2.2 or what might be the problem.  I didn't quiesce JES2 on the 
current 1.13 system before creating the clone for the sandbox, but we've not 
had issues with doing this before for DR testing (not moving to a new release).

Any thoughts/ideas would be most welcome.

TIA,

Rex


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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


::DISCLAIMER::


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



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

Re: Delete NVR entries where ENQ shows from LLA/XCFAS

[Tom Marchant]

On Thu, 5 Jan 2017 03:39:39 -0600, Ravi Gaur wrote:

>Delete datasets from Disk/3390 which are having enqueue from LLA/XCFAS

It would help if we know what data sets. If they are things like SYS1.LINKLIB 
on an alternate IPL volume there are acceptable ways to do it including the 
BYPASSNQ program already mentioned.

>Tried IDCAMS NVR and also ISPF 3.2 (with VOLUME serial no.) get in use 
>message any trick to get the datasets deleted via bypassing enqueue? on 
>this specific volume

There is a way to delete such data sets in ISPF, but I don't remember the 
details. 
Something like this:
Create a data set list using VOLUME.
Enter "D" for the data sets that you want to delete.
Reply to the prompt to delete the non-cataloged version of the data set.

There is a RACF profile that you must have access to in order for this to work.

-- 
Tom Marchant

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

Re: How many FRR stack entries are available?

[Peter Relson]

The manual states
   "The system only guarantees that installations can add two FRRs"
Is that still true for zOS 2?


Yes it is still true. That is not a statement about how much room there is 
for FRRs overall in the FRR stack (which, as it has long been, is 16 
entries worth).

Peter Relson
z/OS Core Technology Design


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

Re: Addressing Question

[Tom Marchant]

On Wed, 4 Jan 2017 16:24:12 -0600, Bill Woodger wrote:

>No. Your CALLs are static.
>

Bill,

It would be helpful if you would quote enough of the message that you 
are replying to to provide context to what your "No" references.

-- 
Tom Marchant

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

Re: IEC141I 013-A8: how to read VS data sets?

[Lizette Koehler]

Robin,
Please delete any part of the email you did a REPLY to that does not pertain to 
your question.  It tends to confuse the issue.

Next, I am not clear on Reading a VS on JES2 Spool.  JES2 Spool has its own 
unique process for creating SYSOUT.  So if you could explain further that could 
help.

If you are asking about a job that abended when trying to Read a VS dataset and 
got an S013-A8, then that is a different question.

When I look up your abend code

An incorrect record format was requested for a SYSIN, SYSOUT, or subsystem data 
set with BSAM or QSAM or for a z/OS UNIX directory with BPAM. One of the 
following conditions was detected:

RECFM=D was specified.
Variable spanned records (VS or VBS) were requested for input.
Both ANSI and machine control characters were specified.

Please show the  JCL from the job that runs good and the job that fails.  You 
can change the dataset name and I think we only need the JCL to see the way it 
is coded.

Again, you would read SYSOUT On JES2 not a VS dataset on JES2.  Unless your 
application is trying to run a JES2 SSI function to read SYSOUT.  

Please provide further details.

And if you could post the complete IEC141 I message, that would also be 
helpful.  Again just change the dataset name.

Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Robin Atwood
> Sent: Thursday, January 05, 2017 5:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IEC141I 013-A8: how to read VS data sets?
> 
> One of our apps abends if trying to read a VS data set on the JES2 spool. The
> message manual tells me this is because it is not allowed to read VS SYSOUT
> using QSAM. Yet we have another application which does exactly that.
> Furthermore, after one day of staring at the code I cannot see any functional
> difference between the two routines:
> both use identical DCB/DCBEs. SDSF can read the data set of course, but I
> expect it has some internal interface. So I searched on what is the correct
> way to read VS data sets and found virtually nothing. Anybody got any
> experience of this?
> 
> Thanks
> Robin
> 

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

Re: Delete NVR entries where ENQ shows from LLA/XCFAS

[Lizette Koehler]

 If these are Linklst'd datasets, then you could 
  1) Build a new LINKLST and remove these datasets in the new LINKLST
  2) Do what you need to with these files (move, delete)
  3) then if you need them back, build a new copy of the linklst

 Everything will depend on what these datasets are and what they are used for 
in your environment.

 It  is a little bit more difficult to provide a better answer.  There are very 
few details to understand the issue.

 Are they in the LINKLST?
 Are they in other processes?  JCL for STCs, for example.
 What are they used for?
 
 
 Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Ravi Gaur
> Sent: Thursday, January 05, 2017 2:40 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Delete NVR entries where ENQ shows from LLA/XCFAS
> 
> Delete datasets from Disk/3390 which are having enqueue from LLA/XCFAS
> Tried IDCAMS NVR and also ISPF 3.2 (with VOLUME serial no.) get in use
> message any trick to get the datasets deleted via bypassing enqueue? on this
> specific volume
> 

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

IEC141I 013-A8: how to read VS data sets?

[Robin Atwood]

One of our apps abends if trying to read a VS data set on the JES2 spool. The 
message manual tells me this is 
because it is not allowed to read VS SYSOUT using QSAM. Yet we have another 
application which does exactly that.
Furthermore, after one day of staring at the code I cannot see any functional 
difference between the two routines: 
both use identical DCB/DCBEs. SDSF can read the data set of course, but I 
expect it has some internal interface. So I 
searched on what is the correct way to read VS data sets and found virtually 
nothing. Anybody got any experience 
of this?

Thanks
Robin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: 05 January 2017 17:59
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Delete NVR entries where ENQ shows from LLA/XCFAS

Lucas Rosalen wrote:

>You could do the right way, which means removing these datasets from LLA and 
>LNKLST.

Agreed! 

>Or you could recklessly use BYPASSNQ program, which can be found in CBT 
>file #749

Hehehe, 'recklessly'? That AC(1) program is a frontend to screen SVCs and then 
misuse "SYSNOENQ" before calling deletion programs like IEHPROGM or IDCAMS.

My storage admins will not like that program at all. So, I can't try that out 
to see if a certain special RACF profile will block this program or not.

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

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

Re: CLOCKxx - ACCURACY Parameter - IEA032E message

[Alan (GMAIL) Watthey]

Glenn,

Now I don't know your exact setup but this is what I have seen.  I don't use 
the accuracy parameter.  I don't see why the STP needs to be using an external 
time source directly to be accurate.  NTP is a nifty protocol that takes 
latency into account right back to the root of the chain so it should be fairly 
accurate so long as the chain is maintained.  At very high accuracy it does 
needs a better protocol but 50ms should be doable with the basic protocol.

STP will only move the CPC time in small increments, about 1 second every 7 
hours I believe.  This is so no application sees the time go backwards.  If you 
change the NTP time by one second then the CPC would be more than 50 ms out for 
just under 7 hours.  To me 6 hours of alerts seems quite reasonable for that 
one second change.

If the HMCs lose connection with the higher NTP server then they 'should' add 
10 seconds to the root dispersion and anyone querying its time, such as STP, 
would then know it is unusable.  Certainly if you had Cisco switches or Brocade 
Ficon Directors getting their time from your HMC they would have noticed this 
increase and would have written a message to their logs saying they were 
switching to local time.  I see that. Occasionally.

After the chain is re-established it takes a few calls for things to settle 
down and the root dispersion to come back down such that the time becomes 
usable again.  At that point all callers will revert back to using NTP time.  
Again I see the Brocades write a log message to this effect.

Now admittedly I have not monitored an HMC as I actually have an NTP server 
(Windows box as it happens) that supplies all the mainframe boxes, switches, 
consoles, HMCs, DASD, etc.  In fact anything on the LAN that supports getting 
NTP time (even tape cameras).  I run a monitor on this box every hour and if 
the root dispersion goes over 10 then I alert.  It gets the time from some LAN 
box somewhere that gets it from somewhere else, etc all the way up to some 
stratum 0 device which is presumably an atomic clock on the Internet but I'm 
guessing that bit.  All I know is that I am at stratum level 6.

Regards,
Alan Watthey
-Original Message-
From: Jousma, David [mailto:david.jou...@53.com] 
Sent: 04 January 2017 3:54 pm
Subject: Re: CLOCKxx - ACCURACY Parameter - IEA032E message

Glenn,

I wasn’t even familiar with this keyword until you brought it up.  However, a 
couple of comments.   In our shop, we have the HMC's acting as NTP clients to 
external NIST servers for time updates, and as NTP servers for STP, and the 
mainframe as NTP server for the rest of the datacenter.   Our HMC's have 
firewall rules configured to allow outbound connections to be able to reach 
NIST.  I realize we could have configured STP to go to NIST directly for time 
updates, but we didn’t want to expose the SE's (even via firewall) to the 
internet for time updates directly.

It would seem to me, that for the accuracy keyword to work, that STP must be 
using external time sources directly?  Or is ACCURACY only really reporting on 
clock steering events > 50 milliseconds(in your case)?

I ask, because we had an event several months back, where our Firewall team 
botched up the rules, and all of our HMC's lost internet access to NIST, and 
even though the boxes phoned home to IBM, our own internal problem 
notifications procedures broke down, and time was allowed to drift for over a 
week.  In our case, STP was fat, dumb, and happy because he was communicating 
nicely with his NTP servers(multiple HMCs), and it was the HMC's that were 
falling out of accuracy.   So, I don’t know if this would help me or not.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Glenn Miller
Sent: Tuesday, January 03, 2017 5:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CLOCKxx - ACCURACY Parameter - IEA032E message

A few months ago we activated the "ACCURACY" parameter with a value of 50 ( the 
default is zero ) on a few of our z/OS systems ( all systems are z/OS V2R1 ).  
We verified that the "IEA034I THE TOD CLOCK ACCURACY MONITOR IS ACTIVE." is 
issued whenever these z/OS systems are IPL'ed.
Until Saturday night, we have never received any "alert" from this TOD CLOCK 
ACCURACY MONITOR.  However, we did receive the following message on each z/OS 
system that has that monitor active:
IEA032E TOD CLOCK ACCURACY LIMITS MAY HAVE BEEN EXCEEDED.

The IEA032E messages occurred around 8PM Eastern Time on December 31, 2016. The 
IEA032E messages were repeated every hour on each z/OS system until about 2AM 
on January 1, 2017, or about 6 hours after they started.  Also, the IEA032E 
messages have not re-occurred since that 2AM timeframe.

Re: Delete NVR entries where ENQ shows from LLA/XCFAS

[Elardus Engelbrecht]

Lucas Rosalen wrote:

>You could do the right way, which means removing these datasets from LLA and 
>LNKLST.

Agreed! 

>Or you could recklessly use BYPASSNQ program, which can be found in CBT file 
>#749

Hehehe, 'recklessly'? That AC(1) program is a frontend to screen SVCs and then 
misuse "SYSNOENQ" before calling deletion programs like IEHPROGM or IDCAMS.

My storage admins will not like that program at all. So, I can't try that out 
to see if a certain special RACF profile will block this program or not.

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

Re: Delete NVR entries where ENQ shows from LLA/XCFAS

[Lucas Rosalen]

You could do the right way, which means removing these datasets from LLA
and LNKLST.
Or you could recklessly use BYPASSNQ program, which can be found in CBT
file #749

---
*Lucas Rosalen*
Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.com
*
LinkedIn: http://br.linkedin.com/in/lrosalen
Phone: +48 (71) 792 809 198


2017-01-05 10:39 GMT+01:00 Ravi Gaur :

> Delete datasets from Disk/3390 which are having enqueue from LLA/XCFAS
> Tried IDCAMS NVR and also ISPF 3.2 (with VOLUME serial no.) get in use
> message any trick to get the datasets deleted via bypassing enqueue? on
> this specific volume
>
> --
> 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: Delete NVR entries where ENQ shows from LLA/XCFAS

[Elardus Engelbrecht]

Ravi Gaur wrote:

>Delete datasets from Disk/3390 which are having enqueue from LLA/XCFAS 
>Tried IDCAMS NVR and also ISPF 3.2 (with VOLUME serial no.) get in use 
>message any trick to get the datasets deleted via bypassing enqueue? on this 
>specific volume

Are those datasets cataloged with the same names (volser in cat entry = volser 
where they are residing) or are they uncataloged duplicates?

What message(s) are you receiving when trying to delete these datasets?

There are good reasons why you can't delete datasets while an ENQ is active.

Rather, try find out who is the owner including your TSO session procs, stop 
these ASIDs and then do your deletion.

This is the safest way. Yes, there is a way to bypass deletion+renaming while 
ENQ is there, but to do that may risk the safety of your datasets and your 
datasets in LLA's iron grip...

If you just want to delete the uncataloged duplicates, you can just vary the 
volser offline and INIT it after double check all VTOC entries. Not a trick 
which I would recommend of course, but ...

Of course, this type of questions have been answered in IBM-MAIN in the past. 
Just search the archives.

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

Delete NVR entries where ENQ shows from LLA/XCFAS

[Ravi Gaur]

Delete datasets from Disk/3390 which are having enqueue from LLA/XCFAS 
Tried IDCAMS NVR and also ISPF 3.2 (with VOLUME serial no.) get in use 
message any trick to get the datasets deleted via bypassing enqueue? on this 
specific volume

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