Re: Paddle temporary fix?

[Barry Merrill]

Button 677 at https://www.mxg.com/thebuttonman

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, February 23, 2023 5:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Paddle temporary fix?

Does anybody remember the SHARE and players for the "Paddle Temporary Fix" of 
Robert Ranie's paddle, and is there an online description? Thanks.



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

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

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

FW: Integrated Catalog record layout

[Barry Merrill]

Resent, first one with prior email included went to junk.

It should be, but it's not:

Change 23.219  The ICF Catalog 05 record variable GATGEN should have
VMAC6156   been input as , instead of one byte, and variable
VMACCTLG   GATWRAP='Y' is now set if the first bit of GATGEN is on,
Aug 29, 2005   to mark that this GDG member has "wrapped"; i.e., its
   generation number has exceeded .  If GATWRAP is on,
   GATGEN=GATGEN-32768 to contain the correct Gen number.
   This discovery was precipitated by IGD07001I ABENDs in
   production, which occurred when a GDG that had GATWRAP
   on for some members, and GATWRAP off for others, when
   that GDG generation number goes from 999 to 1000.
 Normally, when all members of a GDG have wrapped, the
 next catalog action turns off the wrap bit in all of
 the catalog records.  For a "normal" GDG, that should
 happen when the +256th gen is created after wrap, as
 only 255 members can exist in the catalog.  But this
 site had had a very old application that originally
 created +1 thru +5 each day, and then deleted +1 thru
 +4, leaving only +5 in the catalog.  However, back when
 Clinton was President, an application change was made
 that created only +1 thru +3 and deleted only +1 & +2,
 so there were 2 old GVoo's left in the catalog.
 When the GDG wrapped, and when the create of +1 would
 have created G1000V00, those old GVoo's still had
 their wrap bit off, and the production job failed:
   IGD07001I; GDG ROLL IN ERROR - RETURN CODE 140 REASON 122
 Return Code 140:
   Inconsistent or conflicting arguments were provided.
 Reason Code 122:
   Catalog G1000Vxx will cause the GDG to exceed the
   limit of 10,999.
 Programmer Response:
   Clean up the GDG in error then catalog G1000Vxx.
   The site found Information APAR II07276, which explained
   how wrap works, but it says to 'see the "Z" page for
   internal details of the wrap bit interface'.

   So the site asked IBM Support: "We need to identify other
   GDGs that have the same exposure to causing ABENDs.  Can
   I look at the 'Z' page?  Does the 'wrap bit' appear in
   SMF 61, 65, 66 ICF Catalog records?"

   IBM Level 2 Catalog Support refused to answer the quite
   valid question, with this answer:
 "Unfortunately, the 'Z' page in our info APARs refer to
 information meant for IBM eyes only, for helping us get
 to problem determination quicker.  We are not at
 liberty to discuss any control block internals that are
 not provided in our published manuals.  As for
 information in SMF records relating to this, this info
 would be included in the updated record portion
 of the SMF record, however we cannot discuss offsets
 for those either.  I am sorry I cannot be more helpful.
 Please let me know if there are any other questions
 that I can answer for you."

   Even escalation to my IBM Poughkeepsie z/OS support did
   not convince IBM Level 2 Catalog Support to identify
   which bit is the "GATWRAP" bit.  The ICF Support and
   Developers hid behind "OCO", Object Code Only, as the
   reason they could not provide catalog record
   documentation (but DSECTS are NOT CODE!).

   So I suggested the site could create a GDG and force it
   to wrap, and by examining SMF records, we concluded that
   first bit of GATGEN was the GATWRAP bit.

   Then, I remembered I still had lots of archaic printed
   manuals, and located the very old "MVS/XA Catalog
   Diagnosis Reference for DFP Release 1.2", which confirmed
   that the GATWRAP bit was indeed the first bit of the
   GATGEN field in the 05 Catalog Record!

Herbert W “Barry” Merrill, PHD
President-Programmer
Merrill Consultants
MXG Software
10717 Cromwell Drive
Dallas, TX 75229
www.mxg.com
214 351 1966 

ad...@mxg.com for business questions
supp...@mxg.com for technical questions
ba...@mxg.com  



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

Re: Integrated Catalog record layout

[Barry Merrill]

It should be, but it's not:

Change 23.219  The ICF Catalog 05 record variable GATGEN should have
VMAC6156   been input as , instead of one byte, and variable
VMACCTLG   GATWRAP='Y' is now set if the first bit of GATGEN is on,
Aug 29, 2005   to mark that this GDG member has "wrapped"; i.e., its
   generation number has exceeded .  If GATWRAP is on,
   GATGEN=GATGEN-32768 to contain the correct Gen number.
   This discovery was precipitated by IGD07001I ABENDs in
   production, which occurred when a GDG that had GATWRAP
   on for some members, and GATWRAP off for others, when
   that GDG generation number goes from 999 to 1000.
 Normally, when all members of a GDG have wrapped, the
 next catalog action turns off the wrap bit in all of
 the catalog records.  For a "normal" GDG, that should
 happen when the +256th gen is created after wrap, as
 only 255 members can exist in the catalog.  But this
 site had had a very old application that originally
 created +1 thru +5 each day, and then deleted +1 thru
 +4, leaving only +5 in the catalog.  However, back when
 Clinton was President, an application change was made
 that created only +1 thru +3 and deleted only +1 & +2,
 so there were 2 old GVoo's left in the catalog.
 When the GDG wrapped, and when the create of +1 would
 have created G1000V00, those old GVoo's still had
 their wrap bit off, and the production job failed:
   IGD07001I; GDG ROLL IN ERROR - RETURN CODE 140 REASON 122
 Return Code 140:
   Inconsistent or conflicting arguments were provided.
 Reason Code 122:
   Catalog G1000Vxx will cause the GDG to exceed the
   limit of 10,999.
 Programmer Response:
   Clean up the GDG in error then catalog G1000Vxx.
   The site found Information APAR II07276, which explained
   how wrap works, but it says to 'see the "Z" page for
   internal details of the wrap bit interface'.

   So the site asked IBM Support: "We need to identify other
   GDGs that have the same exposure to causing ABENDs.  Can
   I look at the 'Z' page?  Does the 'wrap bit' appear in
   SMF 61, 65, 66 ICF Catalog records?"

   IBM Level 2 Catalog Support refused to answer the quite
   valid question, with this answer:
 "Unfortunately, the 'Z' page in our info APARs refer to
 information meant for IBM eyes only, for helping us get
 to problem determination quicker.  We are not at
 liberty to discuss any control block internals that are
 not provided in our published manuals.  As for
 information in SMF records relating to this, this info
 would be included in the updated record portion
 of the SMF record, however we cannot discuss offsets
 for those either.  I am sorry I cannot be more helpful.
 Please let me know if there are any other questions
 that I can answer for you."

   Even escalation to my IBM Poughkeepsie z/OS support did
   not convince IBM Level 2 Catalog Support to identify
   which bit is the "GATWRAP" bit.  The ICF Support and
   Developers hid behind "OCO", Object Code Only, as the
   reason they could not provide catalog record
   documentation (but DSECTS are NOT CODE!).

   So I suggested the site could create a GDG and force it
   to wrap, and by examining SMF records, we concluded that
   first bit of GATGEN was the GATWRAP bit.

   Then, I remembered I still had lots of archaic printed
   manuals, and located the very old "MVS/XA Catalog
   Diagnosis Reference for DFP Release 1.2", which confirmed
   that the GATWRAP bit was indeed the first bit of the
   GATGEN field in the 05 Catalog Record!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Joe 
Monk
Sent: Saturday, October 22, 2022 8:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Integrated Catalog record layout

The mapping macro should be in SYS1.MACLIB.

Joe

On Sat, Oct 22, 2022 at 7:26 AM Willy Jensen 
wrote:

> I'm ok wth the layout of the SMF record as such, what I am looking for 
> is the layout of the field SMF61CRC.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with 

50 Years of SAS

[Barry Merrill]

  Fifty years ago today, October 9, 1972, I ran my first SAS Program.


  I left the Navy in June, 1972, and in August, my Psychologist friend,
  Dr. L. Rogers Taylor, now working at State Farm Automobile HQ in
  Bloomington, IL, suggested I might find a home there and arranged for
  an interview. At Purdue in 1966, I had written FORTRAN programs for
  his dissertation, using pattern recognition techniques, cluster
  analysis, and vector distance tools from my Master's Research in EE at
  LARS, the Laboratory for Agricultural Remote Sensing. These tools had
  not been previously used in his then-new field of Industrial
  Psychology. His actual application analyzed questionnaires completed by
  Humble Oil Petroleum Engineers, which were then correlated with a
  separate data file that identified those Engineers who HAD found oil
  from those that hadn't, to construct a predictive questionnaire (very
  successfully, he received accolades from his peers for introducing
  pattern recognition to them).  He arranged for an interview with the
  Vice President for Data Processing, Dr. Norman Vincent.

  After completing the required HR forms, my escort very nervously drove
  me to the Corporate HQ Building; he had never even MET a State Farm
  Corporate VP, let alone be in a VP's office! I immediately clicked
  with Norm and met the manager of the brand new "Measurement Unit",
  Dave Vitek, and then spent the day interviewing members of that group
  (and being interviewed/evaluated by them). I started Sept 18, 1972
  at $13800.

  In 1972, the state of the art for IBM mainframe computer capacity
  planning was simple: your company's IBM salesman would visit with your
  company's vice president for data processing, hand him the contract
  for a newer and faster and larger computer for only a few million
  dollars. Dave Vitek had attended (the first?) Boole and Babbage User
  Group (BBUG) annual meeting, where the idea of actually measuring the
  computer system utilization was THE topic. Dave decided that rather
  than just trusting the IBM salesman as your capacity planner, State
  Farm should be able to figure out how measure its own computers, and
  Dave got Norm to fund a ten-person Measurement Unit for three years
  for a feasibility study.

  Steve Cullen had drafted an excellent attack plan to investigate the
  four possible tools, SMF Accounting, Software Monitors, Hardware
  Monitors, and Simulation, and in short order, we had Kommand/PACES for
  accounting, Software Monitors (SYSTEM LEAP and PROGRAM LEAP), Hardware
  Monitors (TESDATA XRAY), and Simulation (SAM). But, Kommand was only
  for billing, with only a few canned reports, and with no tool for data
  extraction, Denny Maguire had started to write PL/1 programs to
  extract fields directly from the raw SMF records. When he mentioned he
  wanted to plot his data. I called Purdue's LARS and they sent me the
 FORTRAN "PLOT" subroutine that I had   written there that did simple
  plots on line printers, but could also print detailed graphics on
 CalComp paper plotters.  Denny was still having problems reading the
 complex data in SMF records, so my PLOT   program was still untested,
 when, in the September, 1972, Datamation, I found this announcement:
   "The Institute of Statistics at North Carolina State University
   announces the availability of the Statistical Analysis System, a
   package of 100,000 lines, one third each in Fortran, PL/1 and
   Assembler, that does printing, analysis and plotting of data. The
   package is available, including source code, for $100.00."

  I wrote for information, and got typical university documentation,
  with some pages dittoed, some pages typed, some printed, each on paper
  of a different color, but I immediately realized the power and
  simplicity and the beauty of the SAS language and especially of power
  of its INPUT statement which could clearly handle the complexity of
  SMF data. However, in their list of supported data field formats,
  there was no reference to support for Packed Decimal fields. You only
  need to get seven bytes into an SMF record to encounter a Packed
  Decimal field, so I called the Institute of Statistics at North
  Carolina State University, and was connected with Tony Barr, the
  designer of the SAS language and the author of the SAS compiler about
  support for that data type. In his North Carolina accent, he replied,
  "Wheall, we haven't got around to documenting it yet, but if you type
  in P D 4 Point, it'll work jest fine", so I convinced State Farm to
  risk the 1972 purchase price of $100 for the SAS package.

  Starting in 1964, Tony Barr and Dr. Jim Goodnight had collaborated to
  develop an ANOVA routine for the Department of Agriculture. Tony had
  been an IBM developer of the data base for the cold war's Distant
  Early Warning (DEW line) radar system, and Jim was a well-known
  statistician. Both recognized the weakness of the existing stat
  packages: they were 

Re: Buttons, we got buttons...

[Barry Merrill]

Button 157 at www.mxg.com/thebuttonman

VS2.2 came with a free Measurement Facility 1, but it was No Fxxxing Good, 
hence this message. At the New York SHARE meeting 18 IBMers came down from 
Poughkeepsie to meet with members of both the CME Project and the MVS 
Performance Project, and what had been scheduled for an hour session extended 
well into the evening, as we went over every field in every record in MF1 and 
educated the IBMers as to what was needed (like, in the RMF 74 record, we 
thought that VOLSER would be useful; MF1 had only provided the UCB Address!), 
Six months later, IBM announced RMF, with almost eveything we asked for fixed, 
but RMF was no longer free. However, because it was now a product, with 
revenue, it was no longer a part of the Operating System, where it had been 
competing with the Paging Supervisor, and the Dispatcher, and all of the other 
components for staff, and so we began to get the enhancements we had needed, 
now that we were paying for them directly.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Wednesday, July 6, 2022 6:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Buttons, we got buttons...

When was MF/1 crossed with NFG?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob 
Bridges [robhbrid...@gmail.com]
Sent: Monday, July 4, 2022 7:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Buttons, we got buttons...

LOL, I clearly remember some buttons on a cubicle wall, buttons a coworker had 
taken home from a sci-fi or possibly software convention (I don't remember).  
The first one I saw said "This universe is full of magical things patiently 
waiting for us to grow smarter".  Another said "Good, fast, cheap: Pick two".

That was in fall 1996; it was the beginning of my tagline file, which you've 
all been suffering from.

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

/* ...critics of democracy, including friendly critics, have always pointed out 
that the Achilles' heel of democracy is its tendency to turn the ballot box 
into an instrument of plunder, as voters learn to vote for those who promise 
them other people's money.  -Joseph Sobran */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gabe Goldberg
Sent: Monday, July 4, 2022 15:33

Bill Bitner (just retired from IBM Endicott after 36 years 11 months) has a 
SHARE/VM/etc. button collection.

At recent VM Workshop celebrating VM's 50th anniversary, I promised to share 
mine, send him any he'd like to add to his trove.

So here are lots of buttons spanning decades!

Spread out on basement floor.

https://secure-web.cisco.com/1bZ1SUd9takSKEgV3DvzE69_yhA3ZJxW6E31R_9ijTRJWy4vmtA3FSeLweEIxh1GzOU8c8nM9fxNRjGBRR2POgJ6uHWLcM5L48OdQVHxC5l6Se-DchzS7GxDodbzDwgT9aAO0WyVPunnxNaga3RlpxITJvyyvY65H2hsS4gTgz0ALkyMgf1uHsYKgOdIP0gA5KM48bHPb4lvQ3W1NwapIbnuOsdQHThCDnFy4Bc3axaP3NSG6Tc4bVKwkJhpkNJ1-X9VfAF9IxR3xv11zwchCI0OfuMmVHRpDBS-JBwNnxVE11QtvU0BGA6PGz4h9TiqjGMOX5xyu1IV81QrNCQuBzyhZJw_DgF-GiRE8EXBS7sWdTg1rFnFQ7m8GGO-KPwXCuis8IFmi6XZ-Y9Va4PUbOBq_Rth_oVGH8S-BZ3eF81P04c05vfYXV5QBxhuKToP-/https%3A%2F%2Fshare.icloud.com%2Fphotos%2F09b-e_A0o9IhBXd6qQ_puAyng

Bunch of photos and a panning video.

I told him to pick what he wants before my wife makes me pick them up!

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

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

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

FW: Trying to understand SMF30_RAXFLAGS

[Barry Merrill]

  MXG decodes these raxflags:

  SMF30_RAXFLAGS='AUDIT*USERKEY*CSA*FLAGS'
  SMF30_RAXFLAG0='RAX0*USERKEY*COMMON*AUDIT*ENABLED?'
  SMF30_RAXFLAG1='RAX1*USERKEY*COMMON*AUDIT*USAGE?'
  SMF30_RAXFLAG2='RAX2*USERKEY*CADS*USAGE?'
  SMF30_RAXFLAG3='RAX3*USERKEY*CHANGE*KEY*USAGE?'
  SMF30_RAXFLAG4='RAX4*USERKEY*RUCSA*USAGE?'
  SMF30_RAXFLAG5='RAX5*ATTEMPT*EARLY*RUCSA?'
  SMF30_RAXFLAG6='RAX6*ALLOW*EARLY*RUCSA?'

 IF SMF30_RAXFLAGS='1...'B THEN SMF30_RAXFLAG0='Y';
 ELSE SMF30_RAXFLAG0=' ';
 IF SMF30_RAXFLAGS='.1..'B THEN SMF30_RAXFLAG1='Y';
 ELSE SMF30_RAXFLAG1=' ';
 IF SMF30_RAXFLAGS='..1.'B THEN SMF30_RAXFLAG2='Y';
 ELSE SMF30_RAXFLAG2=' ';
 IF SMF30_RAXFLAGS='...1'B THEN SMF30_RAXFLAG3='Y';
 ELSE SMF30_RAXFLAG3=' ';
 IF SMF30_RAXFLAGS='1...'B THEN SMF30_RAXFLAG4='Y';
 ELSE SMF30_RAXFLAG4=' ';
 IF SMF30_RAXFLAGS='.1..'B THEN SMF30_RAXFLAG5='Y';
 ELSE SMF30_RAXFLAG5=' ';
 IF SMF30_RAXFLAGS='..1.'B THEN SMF30_RAXFLAG6='Y';
 ELSE SMF30_RAXFLAG6=' ';
-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Charles Mills
Sent: Monday, April 18, 2022 11:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to understand SMF30_RAXFLAGS

Sorry. Bit 0 is usually the X'01' bit in mainframe doc (other than UNIX).

So is my interpretation correct? 

SMF30_USERKEYCSAUSAGE is x'02'?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Monday, April 18, 2022 8:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Trying to understand SMF30_RAXFLAGS

We have a client who is trying to report on user key CSA usage. He is having
trouble understanding the IBM doc, as am I.

The SMF doc I am familiar with documents bits as X'80', X'40', etc. But the
SMF30_RAXFLAGS doc (both the APAR and the new manual) documents the bits as
Bit 0, Bit 1, etc. Usually in mainframe documentation "bit 0" refers to the
x'80' bit. But what the client is seeing is values for SMF30_RAXFLAGS of
binary 1, 2 or 3.

Can anyone confirm my interpretation of what he is seeing that by "bit 0"
IBM means X'01', by "bit 1" they mean x'02', and so forth?

--
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: Trying to understand SMF30_RAXFLAGS

[Barry Merrill]

  MXG decodes as:

  SMF30_RAXFLAGS='AUDIT*USERKEY*CSA*FLAGS'
  SMF30_RAXFLAG0='RAX0*USERKEY*COMMON*AUDIT*ENABLED?'
  SMF30_RAXFLAG1='RAX1*USERKEY*COMMON*AUDIT*USAGE?'
  SMF30_RAXFLAG2='RAX2*USERKEY*CADS*USAGE?'
  SMF30_RAXFLAG3='RAX3*USERKEY*CHANGE*KEY*USAGE?'
  SMF30_RAXFLAG4='RAX4*USERKEY*RUCSA*USAGE?'
  SMF30_RAXFLAG5='RAX5*ATTEMPT*EARLY*RUCSA?'
  SMF30_RAXFLAG6='RAX6*ALLOW*EARLY*RUCSA?'

 IF SMF30_RAXFLAGS='1...'B THEN SMF30_RAXFLAG0='Y';
 ELSE SMF30_RAXFLAG0=' ';
 IF SMF30_RAXFLAGS='.1..'B THEN SMF30_RAXFLAG1='Y';
 ELSE SMF30_RAXFLAG1=' ';
 IF SMF30_RAXFLAGS='..1.'B THEN SMF30_RAXFLAG2='Y';
 ELSE SMF30_RAXFLAG2=' ';
 IF SMF30_RAXFLAGS='...1'B THEN SMF30_RAXFLAG3='Y';
 ELSE SMF30_RAXFLAG3=' ';
 IF SMF30_RAXFLAGS='1...'B THEN SMF30_RAXFLAG4='Y';
 ELSE SMF30_RAXFLAG4=' ';
 IF SMF30_RAXFLAGS='.1..'B THEN SMF30_RAXFLAG5='Y';
 ELSE SMF30_RAXFLAG5=' ';
 IF SMF30_RAXFLAGS='..1.'B THEN SMF30_RAXFLAG6='Y';
 ELSE SMF30_RAXFLAG6=' ';
-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Charles Mills
Sent: Monday, April 18, 2022 11:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to understand SMF30_RAXFLAGS

Sorry. Bit 0 is usually the X'01' bit in mainframe doc (other than UNIX).

So is my interpretation correct? 

SMF30_USERKEYCSAUSAGE is x'02'?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Monday, April 18, 2022 8:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Trying to understand SMF30_RAXFLAGS

We have a client who is trying to report on user key CSA usage. He is having
trouble understanding the IBM doc, as am I.

The SMF doc I am familiar with documents bits as X'80', X'40', etc. But the
SMF30_RAXFLAGS doc (both the APAR and the new manual) documents the bits as
Bit 0, Bit 1, etc. Usually in mainframe documentation "bit 0" refers to the
x'80' bit. But what the client is seeing is values for SMF30_RAXFLAGS of
binary 1, 2 or 3.

Can anyone confirm my interpretation of what he is seeing that by "bit 0"
IBM means X'01', by "bit 1" they mean x'02', and so forth?

--
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: Variable length records for SYSIN data sets

[Barry Merrill]

My very first computer program was about 30 feet of paper tape for
the IBM 610 at Notre Dame in Sep 1959 when I was a Sophomore in EE.
It calculated the value of a 4x4 determinant.

The first output on the Selectric was four characters  WOW!

I sat in the computer room when not in class for three days
until the only other user came in, and he helped me to understand
the difference between program and data, and showed me that the
first character on my paper tape told the reader to look for
a control character, and in the fifth from end character it 
found a control character that told the reader to print out 
the tape characters as instructions, and thereby printed
the last four instructions in my program:
Carriage Return, Line Feed, Carriage Return, Print Accumulator, WOW!

(The second CR was to get the Selectric all the way back to the left
before it printed the result.)


Barry


Herbert W "Barry" Merrill, PHD
President-Programmer
Merrill Consultants
MXG Software
10717 Cromwell Drive
Dallas, TX 75229
www.mxg.com
214 351 1966 

ad...@mxg.com for business questions
supp...@mxg.com for technical questions
ba...@mxg.com  



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Seymour J Metz
Sent: Thursday, October 28, 2021 8:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Variable length records for SYSIN data sets

We burned the paper tape and scattered the ashes. Please don't bring it
back.


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



From: IBM Mainframe Discussion List  on behalf of
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, October 28, 2021 9:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Variable length records for SYSIN data sets

On Fri, 29 Oct 2021 12:03:14 +1100, Robin Vowels wrote:

>We used to use RECFM=V in the 1960s with SYSIN for PL/I source programs 
>on paper tape.
>
What have we abandoned in the 20th Century?!

Where can he order one?  RPQ?

>On 2021-10-29 11:56, Paul Gilmartin wrote:
>> On Thu, 28 Oct 2021 22:49:49 +, Seymour J Metz wrote:
>>
>>> What happens with
>>>
>>>//INFILE   DD DISP=SHR,DSN=MY.VB.FILE
>>>// DD *,DCB=(RECFM=V,LRECL=204)
>>>
>>> and have you reported it as a bug, citing the text that you quoted?
>>>
>> I haven't RTFM today, but I believe it has long been a documented 
>> restriction.
>> I've readily used:
>> o An Edit macro which does EXECIO to a DDNAME allocated with RECFM=VB 
>> o FTP with "QUOTE SITE FILE=JES"; "QUOTE SITE JESRECFM=V"
>> o IEBGENER witn //SYSUT2 DD SYSOUT=(B,INITRDR) o  Etc.
>>
>> Not a bug; WAD.  Merits an RFE.
>>
>>> 
>>> From:Frank Swarbrick
>>> Sent: Thursday, October 28, 2021 5:11 PM
>>>
>>> I have a goal to concatenate a data set of variable length records
>>> (RECFM=VB,LRECL=204) with an instream data set of fixed length 
>>> characters.  My though was to add RECFM=V to my instream DD, i.e.:
>>> //INFILE   DD DISP=SHR,DSN=MY.VB.FILE
>>> // DD *,RECFM=V,LRECL=204
>>>
>>> The RECFM is rejected as being conflicting with a SYSIN dataset:
>>> IEFC009I KEYWORD RECFM IS MUTUALLY EXCLUSIVE WITH KEYWORD SYSIN ON 
>>> THE DD STATEMENT
>>>
>>> And yet the following section of the manual, "SYSIN data set" has 
>>> discussion of SYSIN data sets where "the record format is variable":
>>> https://www.ibm.com/docs/en/zos/2.5.0?topic=ssds-sysin-data-set
>>>
>>> But how do I actually make the SYSIN dataset variable length?
>>>
>>> I do realize there are probably other options to accomplish my task, 
>>> but this is bugging me.
>>>
>> RFE.

-- gil

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

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

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

Re: Return Code = 26530, Error Code = 00011 on RFN from IBM

[Barry Merrill]

>From my ftping notes:


17. EZA1735I Std Return Code=26530, Error Code=00011
EZYFS34W FTP will not remove TRAILING sequence numbers.
530 Not Logged In

The primary cause is incorrect password (i.e., password in Upper
Case when it should be lower case, or wrong/misspelled password).

One site received this error using the actual ip address of the
MXG ftp site, but using the ftp.mxg.com url, the login worked.

The user claimed the standard MXG SYSIN was used and it caused
the above error, but that he was able to use this syntax to get
logged in and download the file:
  //SYSINDD *
  ftpv2...@ftp.mxg.com
  thePASSWORD
  quote PASV
  BINARY
  LOCSITE LRECL=1024 RECFM=FB BLKSIZE=6144 UNIT=SYSDA
  LOCSITE PRIMARY=5000 SECONDARY=300
  GET ter2806.ter 'MXG.mxg2806.TERSED' (replace
  CLOSE
  QUIT
A second site received the same return code/error code, and
reported that their site required this syntax in the first two
control cards:
  mxgtech@localuse...@ftp.mxg.com
  mxgtech@localpassword
(But only ONE site said this worked, long ago, and I doubt it.)
But a third site got that return/error code, but had this
message from ftp:
  EZYFS34W FTP will not remove TRAILING sequence numbers.
because their SYSIN was NUMBERED but must be UNNUMBERED.

Herbert W "Barry" Merrill, PHD
President-Programmer
Merrill Consultants
MXG Software
10717 Cromwell Drive
Dallas, TX 75229
www.mxg.com
214 351 1966 

ad...@mxg.com for business questions
supp...@mxg.com for technical questions
ba...@mxg.com  



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Richards, Robert B. (CTR)
Sent: Monday, October 4, 2021 6:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Return Code = 26530, Error Code = 00011 on RFN from IBM

Subject says it all. I am trying to order some PTFs.

Is anyone else receiving the error below this fine Monday morning?

Connecting to: dispby-117.boulder.ibm.com 170.225.15.117 port: 21.
220 ProFTPD Server (proftpd) [170.225.15.117]
>>> AUTH TLS
234 AUTH TLS successful
Authentication negotiation succeeded
>>> PBSZ 0
200 PBSZ 0 successful
>>> PROT P
200 Protection set to Private
Data connection protection is private
NAME (deliverycb-bld.dhe.ibm.com:XXX):

> S54962e8
>>> USER S54962e8
331 Password required for S54962e8
PASSWORD:

> ***
>>> PASS
530 Login incorrect.
Std Return Code = 26530, Error Code = 00011
>>> QUIT
221 Goodbye.

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

FW: SPF/SE... out of business

[Barry Merrill]

 

I received this email from Tim in January.

 

Barry

Herbert W “Barry” Merrill, PHD

President-Programmer

Merrill Consultants

MXG Software

10717 Cromwell Drive

Dallas, TX 75229

 <http://www.mxg.com/> www.mxg.com

214 351 1966 

 

 <mailto:ad...@mxg.com> ad...@mxg.com for business questions

 <mailto:supp...@mxg.com> supp...@mxg.com for technical questions

 <mailto:ba...@mxg.com> ba...@mxg.com  

 

 

 

From: spfsupp...@aol.com <mailto:spfsupp...@aol.com>  mailto:spfsupp...@aol.com> > 
Sent: Tuesday, January 5, 2021 12:09 PM
To: supp...@mxg.com <mailto:supp...@mxg.com> 
Subject: Re: EDITOR Not Working 3454 - DEAD IN THE WATER

 

Hello Barry, 

 

I am in a Covid-19 Quarantine.  Wife and I tested positive last Wednesday.  No 
treatment offered, just double up on Vitamin C, D, and Zinc.  Hanging in with a 
raspy cough for last 5 days.  Hope for improvement soon.  Will have to suspend 
SPF activities for a while.

 

Tim

 

  


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

z/TPF Questions

[Barry Merrill]

MXG Support for TPF:

 

Change 17.200  Support for IBM's TPF Operating System.

EXTPFxxForty datasets are created from the fifty or so records.

FORMATSSome datasets are written at monitor initialization to

IMACTPFmap things, but the interval records are deaccumulated

TPFINTRV   and written as individual PDB datasets, and then TPFINTRV

TYPETPFis invoked to summarize into PDB.TPFINTRV.  This support

VMACTPFhas been tested with data from one system, and TPFINTRV

VMXGINIT   intervals the SA/NX/SX/SU/SP/MD/MG/FV/FS/SC records.

VMXGTPFI   This is preliminary support, but TPFINTRV and its input

Aug  2, 1999   datasets have been tested extensively; there are still a

   number of questions and some variable names may change.

  For over two years I have requested the DSECTS for the

  TPF records; it took a vote of the TPF Users Group to

  "convince" IBM it would be worthwhile to allow MXG to

  support this high-speed transaction processing system.

  Formerly know at the Airline Control Program, it can

  drive 30,000 I/Os per second on an 8-engines CPC!

   The initial development of the VMACTPF code took 40 hours

   across four days to write about 4,000 lines of SAS code.

   Another 40 hours were required to add the roughly 400

   lines to deaccumulate and validate the PDB.TPFINTRV data.

   Thanks to Jack Opgenorth, Sabre, USA.

   Thanks to Linda Tallent, Sabre, USA.

 

Last Change:

 

Change 28.152  Support for zTPFC, TPF Continuous Monitoring has a few

EXTPFC92   fields added to existing datasets and two new datasets

EXTPFC98   added by this change

IMACTPFC

VMACTPFC  DDDATASET   Description

Jul  2, 2010

Jul 21, 2010  TPFC92TPFC92LPAR UTILIZATION

  TPFC98TPFC98DASD SERVICE TIME

   Thanks to Bob Wilcox, HP, USA.

 

Herbert W "Barry" Merrill, PHD

President-Programmer

Merrill Consultants

MXG Software

10717 Cromwell Drive

Dallas, TX 75229

www.mxg.com <http://www.mxg.com/> 

214 351 1966 

 

ad...@mxg.com <mailto:ad...@mxg.com>  for business questions

supp...@mxg.com <mailto:supp...@mxg.com>  for technical questions

ba...@mxg.com <mailto:ba...@mxg.com>   

 


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

Re: Z15 zedc compression and CONNECT DIRECT, MFT compression

[Barry Merrill]

Duh, Go to OFFSET and INPUT the LENGTH field.

Barry

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Barry Merrill
Sent: Friday, December 11, 2020 11:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Z15 zedc compression and CONNECT DIRECT, MFT compression

It is very common for SMF "Triplets" of Offset, Length, and Count to
populate the OFFSET, but to not populate the Count for segments that do not
exist in the record.  And there can be more than one triplets with that same
OFFSET populated but with Counts zero.

It is also common to see segments that are present with OFFSET and COUNT
populated but with the LENGTH zero, which means you have to go to OFFSET and
INPUT the count field to process those segments.

Barry


Herbert W “Barry” Merrill, PHD
President-Programmer
Merrill Consultants
MXG Software
10717 Cromwell Drive
Dallas, TX 75229
www.mxg.com
214 351 1966 

ad...@mxg.com for business questions
supp...@mxg.com for technical questions
ba...@mxg.com  



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Jousma, David
Sent: Wednesday, December 9, 2020 12:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Z15 zedc compression and CONNECT DIRECT, MFT compression

If you are using MXG with SAS, its likely you might need an update there?


_
Dave Jousma
AVP | Director, Technology Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids,
MI 49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Kenneth J. Kripke
Sent: Wednesday, December 9, 2020 12:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Z15 zedc compression and CONNECT DIRECT, MFT compression

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**

Hello; 

 We have upgraded from a Z14 to Z15 processor, and, have experienced
something curious regarding the SMF TYPE 30 section being generated for
Connect Direct as well as Tibco's MFT 8.0 file transfer products.  

Both products are enabled to use ZEDC compression, but, when generating SAS
reports from SMF type 30 records, we  see   SMF30USO{Offset to zEDC usage
statistics Section} and the, SMF30USL{Length of zEDC usage statistics
Section}  containing data.  

We do not see the SMF30USN{Number of zEDC usage statistics sections} having
data.  This has been noticed since upgrading from a z14 to a z15 processor.
Has anyone else seen anything like this in their environment running MFT 8.0
or Connect Direct ? 

 

Kenneth J. Kripke

3433 Plumtree Drive

Apt. K

Ellicott City, MD.  21042

Phones:

Land:  410-696-2307

Cell:443-851-1237

k.kri...@comcast.net <mailto:k.kri...@comcast.net>   Preferred 

kennethkri...@gmail.com <mailto:kennethkri...@gmail.com>  

 


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

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**

This e-mail transmission contains information that is confidential and may
be privileged.   It is intended only for the addressee(s) named above. If
you receive this e-mail in error, please do not read, copy or disseminate it
in any manner. If you are not the intended recipient, any disclosure,
copying, distribution or use of the contents of this information is
prohibited. Please reply to the message immediately by informing the sender
that the message was misdirected. After replying, please erase it from your
computer system. Your assistance in correcting this error is appreciated.

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

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

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

Re: Z15 zedc compression and CONNECT DIRECT, MFT compression

[Barry Merrill]

It is very common for SMF "Triplets" of Offset, Length, and Count 
to populate the OFFSET, but to not populate the Count for segments
that do not exist in the record.  And there can be more than one
triplets with that same OFFSET populated but with Counts zero.

It is also common to see segments that are present with 
OFFSET and COUNT populated but with the LENGTH zero, 
which means you have to go to OFFSET and INPUT the count field to
process those segments.

Barry


Herbert W “Barry” Merrill, PHD
President-Programmer
Merrill Consultants
MXG Software
10717 Cromwell Drive
Dallas, TX 75229
www.mxg.com
214 351 1966 

ad...@mxg.com for business questions
supp...@mxg.com for technical questions
ba...@mxg.com  



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Jousma, David
Sent: Wednesday, December 9, 2020 12:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Z15 zedc compression and CONNECT DIRECT, MFT compression

If you are using MXG with SAS, its likely you might need an update there?


_
Dave Jousma
AVP | Director, Technology Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids,
MI 49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Kenneth J. Kripke
Sent: Wednesday, December 9, 2020 12:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Z15 zedc compression and CONNECT DIRECT, MFT compression

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**

Hello; 

 We have upgraded from a Z14 to Z15 processor, and, have experienced
something curious regarding the SMF TYPE 30 section being generated for
Connect Direct as well as Tibco's MFT 8.0 file transfer products.  

Both products are enabled to use ZEDC compression, but, when generating SAS
reports from SMF type 30 records, we  see   SMF30USO{Offset to zEDC usage
statistics Section} and the, SMF30USL{Length of zEDC usage statistics
Section}  containing data.  

We do not see the SMF30USN{Number of zEDC usage statistics sections} having
data.  This has been noticed since upgrading from a z14 to a z15 processor.
Has anyone else seen anything like this in their environment running MFT 8.0
or Connect Direct ? 

 

Kenneth J. Kripke

3433 Plumtree Drive

Apt. K

Ellicott City, MD.  21042

Phones:

Land:  410-696-2307

Cell:443-851-1237

k.kri...@comcast.net <mailto:k.kri...@comcast.net>   Preferred 

kennethkri...@gmail.com <mailto:kennethkri...@gmail.com>  

 


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

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**

This e-mail transmission contains information that is confidential and may
be privileged.   It is intended only for the addressee(s) named above. If
you receive this e-mail in error, please do not read, copy or disseminate it
in any manner. If you are not the intended recipient, any disclosure,
copying, distribution or use of the contents of this information is
prohibited. Please reply to the message immediately by informing the sender
that the message was misdirected. After replying, please erase it from your
computer system. Your assistance in correcting this error is appreciated.

--
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: Is there a tool to monitor JES2 Input Queue wait time? [EXTERNAL]

[Barry Merrill]

MXG provides two Input Queue Time analysis programs in members ASUMJOBS and
ANALBATQ.

Barry


Herbert W “Barry” Merrill, PHD
President-Programmer
Merrill Consultants
MXG Software
10717 Cromwell Drive
Dallas, TX 75229
www.mxg.com
214 351 1966 

ad...@mxg.com for business questions
supp...@mxg.com for technical questions
ba...@mxg.com  



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Feller, Paul
Sent: Tuesday, August 25, 2020 9:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there a tool to monitor JES2 Input Queue wait time?
[EXTERNAL]

Lizette, if you have some type of software like OPS/MVS you could look at
running a script from time to time that executes the JES2 command
$DJQ,DELAY=YES,DELAY and then look at the output from the command.  Not
"real" time but next to it.

This is from a little test I did.

$DJQ,DELAY=YES,DELAY   
$HASP890 JOB(UDT014E6)  DELAY=(HOLD)   
$HASP890 JOB(UDT014E6)  DELAY=(HOLD,SCHENV)



Thanks.. 
  
Paul Feller
GTS Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Lizette Koehler
Sent: Monday, August 24, 2020 3:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Is there a tool to monitor JES2 Input Queue wait time? [EXTERNAL]

Just curious

 

We had a few jobs that took up to 30 minutes before going from input queue
to actually running.

 

Does anyone know of an easy (FREE) way to monitor JES2 Input times?

 

I know sometimes it is due to resource restrictions and WLM will not allow
anything else to run.

 

But any way to see it in real time? (Assume Lights Out Environment - no
people watching)

 

 

 

Thanks 

 

Lizette

 


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

--
Please note:  This message originated outside your organization. Please use
caution when opening links or attachments.

--
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: SORT Capacity Exceeded

[Barry Merrill]

Could you elaborate on why and when AVGRECLEN allocation is more efficient?

Barry


Herbert W "Barry" Merrill, PHD
President-Programmer
Merrill Consultants
MXG Software
10717 Cromwell Drive
Dallas, TX 75229
www.mxg.com
214 351 1966 

ad...@mxg.com for business questions
supp...@mxg.com for technical questions
ba...@mxg.com  



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Sri h Kolusu
Sent: Wednesday, July 29, 2020 9:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SORT Capacity Exceeded

> ICE752I 0 FSZ=100121518644 BC  IGN=0 E  AVG=16336 0  WSP=130040639 C
DYN=0 0
> ICE236I 0 OPTIONS:
DYNAPCT=10 ,MOWRK=Y,TUNE=STOR,EXPMAX=600,EXPOLD=200,EXPRES=100


Robert,

The file you are trying to sort is little over 100 Gigs, but your
installation option EXPMAX=600 MB which is only 0.6 Gigs ( EXPMAX -
specifies the maximum total amount of available storage to be used at any
one time by all Hipersorting, memory object sorting and dataspace sorting
applications.) So DFSORT has to complete the entire sort using sortwk
datasets which I believe are under-allocated.

As Mike and kees suggested it is advisable to get rid off the JCL sortwk
allocation and use DFSORT dynamic allocation.  So change your sysin to the
following. I also added the average length parm which will allow DFSORT to
allocate the sortwk space more efficiently

//SYSINDD *
  OPTION DYNALLOC=(,32),AVGRLEN=1486
  SORT FIELDS=(5,1,CH,A,9,35,CH,A,44,8,CH,D)
/*

Further if you have any questions please let me know

Thanks,
Kolusu

--
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: Help with technique to identify data for last time/date an event occurred

[Barry Merrill]

%let macfile= %QUOTE( IF ID=30 and subtype=5; ) ;
%include sourclib(type30);
PROC SORT DATA=TYPE30_5;
BY JOB DESCENDING READTIME;
DATA TIMES;
BY JOB;
IF FIRST.JOB THEN PUTLOG JOB= JESNR= READTIME= TERMTIME= ABEND=;

Barry

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Lizette Koehler
Sent: Friday, July 24, 2020 1:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Help with technique to identify data for last time/date an event
occurred

I have the following data

 

JOBN1 JOBNO  DATE-RAN  TIME-RAN  Condition-Code

JOB123123456  22Jul20201000   0

JOB123123356  22Jul2020   0

JOB123120056  22Jul20200100   0

JOB123A  121156  22Jul20201300   0

JOB123B  122356  22Jul20200100   0

JOB123B  125656  22Jul20201325   0

JOB123C  120956  22Jul20201300   0

JOB123D  121756  22Jul20202300   0

 

 

I am not sure what would be the best way to get the following output

 

I just want the job (plus details) from the last run.  So if a job name runs
10 times, what is the very last time it ran

 

JOB123123456  22Jul20201000   0

JOB123B  125656  22Jul20201325   0

JOB123C  120956  22Jul20201300   0

JOB123D  121756  22Jul20202300   0

 

 

I can put it in an Excel and possibly use LAST or MIN/MAX functions

 

I can probably code REXX to do this

 

Maybe even DFSORT/ICETOOL

 

 

Just not sure what would be the easiest.  I will have several million
entries where I just need the last time a specific job ran.

 

 

 

Thanks

 

 


--
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: SMF 71 long floating point fields

[Barry Merrill]

-Original Message-
From: Barry Merrill  
Sent: Thursday, June 11, 2020 10:02 AM
To: 'pr...@videotron.ca' 
Subject: RE: SMF 71 long floating point fields

To SAS, they are straightforward RB8. fields with exponent and mantissa.

SMF71AFB=80737.714286 RBCHAR=4513B61B6DB6DB6D
SMF71AFB=80700.142857 RBCHAR=4513B3C249249249
SMF71AFB=80701.285714 RBCHAR=4513B3D492492492
SMF71AFB=80811.428571 RBCHAR=4513BAB6DB6DB6DB
SMF71AFB=80817.571429 RBCHAR=4513BB1924924924
SMF71AFB=80786.714286 RBCHAR=4513B92B6DB6DB6D
SMF71AFB=80867.857143 RBCHAR=4513BE3DB6DB6DB6
SMF71AFB=80680.428571 RBCHAR=4513B286DB6DB6DB
SMF71AFB=80578.285714 RBCHAR=4513AC2492492492
SMF71AFB=80708.428571 RBCHAR=4513B446DB6DB6DB
SMF71AFB=80688.714286 RBCHAR=4513B30B6DB6DB6D
SMF71AFB=80779 RBCHAR=4513B8B0

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pierre Fichaud
Sent: Wednesday, June 10, 2020 6:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMF 71 long floating point fields

There are many of them. I'm guessing these are hex floating point.
Could someone confirm this or correct me ?
Thanks, Pierre.

--
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: DCOLLECT use of KB/MB

[Barry Merrill]

It all depends; this is the logic for the 'V' record
which comes in two flavors, with value of bytes the
result of this code:

   IF DCVCYLMG=' ' THEN DO; /* UNITS ARE KB*/
 DCVALLOC=1024*DCVALLOC; /*CONVERT TO BYTES FOR MGBYTES FORMAT*/
 DCVFRESP=1024*DCVFRESP;
 DCVLGEXT=1024*DCVLGEXT;
 DCVVLCAP=1024*DCVVLCAP;
 DCVTRFSP=1024*DCVTRFSP;
 DCVTRALC=1024*DCVTRALC;
 DCVTRVLC=1024*DCVTRVLC;
 DCVTRLGE=1024*DCVTRLGE;
   END;
   ELSE IF DCVCYLMG='Y' THEN DO; /* UNITS ARE MB*/
 DCVALLOC=1048576*DCVALLOC; /*CVERT TO BYTES FOR MGBYTES FORMAT*/
 DCVFRESP=1048576*DCVFRESP;
 DCVLGEXT=1048576*DCVLGEXT;
 DCVVLCAP=1048576*DCVVLCAP;
 DCVTRFSP=1048576*DCVTRFSP;
 DCVTRALC=1048576*DCVTRALC;
 DCVTRVLC=1048576*DCVTRVLC;
 DCVTRLGE=1048576*DCVTRLGE;
   END;


All of the other byte-containing fields in the other DCOLLECT records
are multiplied by 1024 to convert their KB to bytes, and all
byte-containing variables in MXG are in bytes, but formatted
with MGBYTES format to print with K/M/G/ etc suffix.

Barry


Herbert W “Barry” Merrill, PHD
President-Programmer
Merrill Consultants
MXG Software
10717 Cromwell Drive
Dallas, TX 75229
www.mxg.com
214 351 1966 

ad...@mxg.com for business questions
supp...@mxg.com for technical questions
ba...@mxg.com  




-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Smith
Sent: Monday, October 28, 2019 4:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DCOLLECT use of KB/MB

 What does "kilobytes" and "megabytes" mean to DCOLLECT, specifically, type "V" 
(volume) records in the values it shows for volume capacity, and several 
related fields?  i.e. does KB=1000 or KB=1024?  After spending considerable 
time perusing the fine manual, I haven't seen a hint.

btw, my attempt to search the list on https://listserv.ua.edu/cgi-bin/wa
returned nothing for any term I tried (including 'MVS').

--
sas

--
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: IBM SSI Function Codes 16 and 17

[Barry Merrill]

The SMF42PTS datetimestamp is the OPEN date AND the OPEN time.

Barry


Herbert W “Barry” Merrill, PHD
President-Programmer
Merrill Consultants
MXG Software
10717 Cromwell Drive
Dallas, TX 75229
www.mxg.com
214 351 1966 

ad...@mxg.com for business questions
supp...@mxg.com for technical questions
ba...@mxg.com  





-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: Saturday, October 5, 2019 2:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM SSI Function Codes 16 and 17

 On Saturday, October 5, 2019, 08:53:07 AM PDT, Charles Mills 
 wrote:
 
 > I was assuming (yes, I know) that the OP wanted realtime notification of the 
 > OPEN, 
> based on the mention of exits.
> If not, SMF14OPE is pretty good. It gives the time but not the date, which is 
> kind of half an answer.


>From the SMF exit, you can get the current TOD. I'm not sure at what stage of 
>the open the exit is called but I suspect it's at open complete. Is this time 
>not accurate enough? Or do you need from start of OPEN and end of CLOSE?

>From the SMF data, the time will have the same accuracy mentioned. The date 
>will be the header date plus 1 if the open time is less than the header time.

Since the time difference is not available, maybe you can somehow save the open 
time in the DCB or ACB.

The times can be affected by dispatching or swap out. You will need to 
incorporate this into your requirements. 

If all else fails, SVC screening could be a last resort consideration. I don't 
recommend it but you often do what you have to do. Just make sure you take 
extreme precautions.

Jon.  

--
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: CPU time cost of dynamic allocation

[Barry Merrill]

 In z/OS 1.12, the original CPITCBTM and CPISRBTM "Initiator" TOTAL
 CPU times were (finally!) separated into the Init-to-Load "INIT" CPU
 times (CPITCITM/CPISRITM) for the CPU times prior to LOADTIME,
 and into "TERM" CPU times (CPITCTTM/CPISRTTM) from the end of your
 program execution until the last SMF record is written 
 (steps with MANY DD's write MANY SMF 30 subtype 4 records for a
 single step, and more records at job termination for the last step).

 This schematic maps the where the CP Engine CPU times in SMF 30-4
 Step Termination Records are recorded:


  FIRST SMFLAST SMF
   INITTIME   ALOCTIME   LOADTIME  TERMTIME TERMTIME
   1->2--34www5
   |  |   |   |   |
   |<-DSENQ-->|<-ALOCTM->||   |
   |  |  ||   |
   |  |   ||   |
   |I||TTT|
   |  CPITCITM   |CPUTCBTM|  CPITCTTM |
   |  CPISRITMCPUSRBTM|  CPISRTTM |
  CPUHPTTM
  CPUIIPTM
  CPURCTTM

Barry


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Tuesday, August 6, 2019 2:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CPU time cost of dynamic allocation

Can you please clarify? Your first sentence seems to say that SVC 99 (or do you 
mean Initiator) CPU time is in the SMF 30? Can you be more specific?

Your last sentence seems to say the opposite? Or ... ?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Allan Staller
Sent: Tuesday, August 6, 2019 12:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CPU time cost of dynamic allocation

This allocation time can be calculated from SMF type 30.
I am sure time is tracked. I am not sure the associated CPU is tracked.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Tuesday, August 6, 2019 11:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CPU time cost of dynamic allocation

On Tue, 6 Aug 2019 12:25:05 -0400, Charles Mills wrote:
>
>OTOH I have an IEFBR14 batch job on the same machine that allocates 15 
>temporary datasets in JCL. The entire job lock, stock and barrel uses 
>(according to IEF032I) .00 CPU seconds.  Can anyone explain why JCL 
>allocation is apparently much more CPU efficient than SVC 99 allocation?

--
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: MXG error reading z/OS 2.3 data

[Barry Merrill]

The invalid VBS segment message is completely inside SAS and MXG has no way to 
detect
because SAS has already moved on to the next valid VBS segment.

The most common cause that I've seen is when one of the dump jobs to a B37 Out 
of
Space, and that last record was not truncated, and the error occurs when that 
file
is concatenated.  

Be happy that SAS was able to recover and read the rest of the file.

Barry


Herbert W “Barry” Merrill, PHD
President-Programmer
Merrill Consultants
MXG Software
10717 Cromwell Drive
Dallas, TX 75229
www.mxg.com
214 351 1966 

ad...@mxg.com for business questions
supp...@mxg.com for technical questions
ba...@mxg.com  



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Beesley, Paul
Sent: Tuesday, July 9, 2019 4:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MXG error reading z/OS 2.3 data

Thank you for responses.

Unfortunately there is nothing in SASLOG resembling diagnostics to explain what 
is wrong with the rejected record.

I ran IFASMFDP to copy the file, and there were no errors. Number of records 
matches so none were dropped, and the breakdown of record types matches as well.

I can also browse the entire file with FileAid.

I think MXG is telling untruths 

Paul

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Monday, July 08, 2019 4:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MXG error reading z/OS 2.3 data

Also, depending on the record type, I think Dr. Barry has some diagnostics when 
MXG hits an invalid SMF record, check your SASLOG for some diagnostics showing 
the invalid record(s).
been a while since I've used SAS/MXG but I believe this is still the case



Carmen Vitullo

- Original Message -

From: "Ron Hawkins" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, July 8, 2019 9:59:40 AM
Subject: Re: MXG error reading z/OS 2.3 data

Paul,

The problem is not SAS or MXG.

It means you have an out-of-sequence or missing segment of a spanned record in 
the file.


RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Beesley, Paul
Sent: Monday, 8 July 2019 21:34
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] MXG error reading z/OS 2.3 data

Using MXG 32.04 with SAS 9.1.3, reading a mix of z/OS 2.1 and 2.3 data, I get 
this message and RC=4
ERROR: FOR FILE SMF, INVALID VBS SEGMENT DETECTED. PROCESSING IS CONTINUING TO 
THE NEXT RECORD.
Also tried using MXG 36.04 (which required hotfix 37166 for SAS).
Processed only the 2.3 dataset to narrow it down.
Is this anything to worry about?
How can I tell which record it is complaining about?

Thanks

Paul

Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading 
names used by the Atos group. The following trading entities are registered in 
England and Wales: Atos IT Services UK Limited (registered number 01245534), 
Atos Consulting Limited (registered number 04312380), Atos Worldline UK Limited 
(registered number 08514184) and Canopy The Open Cloud Company Limited 
(registration number 08011902). The registered office for each is at Second 
Floor, Mid City Place, 71 High Holborn, London, WC1V 6EA.
The VAT No. for each is: GB232327983.

This e-mail and the documents attached are confidential and intended solely for 
the addressee, and may contain confidential or privileged information.
If you receive this e-mail in error, you are not authorised to copy, disclose, 
use or retain it. Please notify the sender immediately and delete this email 
from your systems. As emails may be intercepted, amended or lost, they are not 
secure. Atos therefore can accept no liability for any errors or their content. 
Although Atos endeavours to maintain a virus-free network, we do not warrant 
that this transmission is virus-free and can accept no liability for any 
damages resulting from any virus transmitted. The risks are deemed to be 
accepted by everyone who communicates with Atos by email.

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

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


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN Atos, Atos Consulting, 
Worldline and Canopy The Open Cloud Company are trading names used by the Atos 
group. The following trading entities are registered in England and Wales: Atos 
IT Services UK Limited (registered number 01245534), Atos Consulting Limited 
(registe

Re: SMS Compression measurment?

[Barry Merrill]

Scott Barry's Share Session 24421 in Phoenix this Spring
provides a good analysis of zEDC analysis, including this
list of relevant SMF records.

Here are the various SMF/DCOLLECT record references:
-   RMF 74 subtype 9
-   SMF type 14/15
-   SMF type 30, zEDC data-section
-   SMF type 23 (for SMF Logstreams and zEDC compression)
-   SMF type 88 (again, for SMF Logstreams / compression)
-   DCOLLECT – record types “D” (Dataset/VTOC), “M” (Migrated) and “B” 
(Backup).

Barry Merrill


Herbert W “Barry” Merrill, PHD
President-Programmer
Merrill Consultants
MXG Software
10717 Cromwell Drive
Dallas, TX 75229
www.mxg.com
214 351 1966 

ad...@mxg.com for business questions
supp...@mxg.com for technical questions
ba...@mxg.com  



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tim 
Hare
Sent: Monday, April 22, 2019 3:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMS Compression measurment?

I can't remember if I posted this before, but it's come up again so I'm asking.

Is there any way, short of running a job with SMS turning compression, and 
running it a different time with compression off, to measure the CPU time used 
by SMS compression for a dataset? I know I can get zEDC CPU savings estimates 
from zBNA and I'm pursuing that path too, but it seems to me it's something 
that ought to be reported;  especially since recent versions of z/OS have zEDC 
measurements reported to SMF.

--
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: part of TSO commands are no RESPONSE from PGM=IKJEFT01

[Barry Merrill]

Only TSO commands that internally use GETLINE/PUTLINE instead of TGET/TPUT 
macros can be executed under TSO in batch.  You can tell by trying it, and if 
it works, then the command used GETLINE/PUTLINE.  A command using TGET/TPUT 
causes the job to act likeit was not executed or to terminate at that point 
without executing
further commands in the input stream.

Barry Merrill

Herbert W “Barry” Merrill, PHD
President-Programmer
Merrill Consultants
MXG Software
10717 Cromwell Drive
Dallas, TX 75229
www.mxg.com
214 351 1966 

ad...@mxg.com for business questions
supp...@mxg.com for technical questions
ba...@mxg.com  



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jason Cai
Sent: Wednesday, March 27, 2019 10:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: part of TSO commands are no RESPONSE from PGM=IKJEFT01

Hi 

The part of output  is correct. the others of output is empty.

Whether there are a lot of XQUERY in one job?



Best Regards,
Jason Cai

 
From: Hobart Spitz
Date: 2019-03-25 21:14
To: IBM-MAIN
Subject: Re: part of TSO commands are no RESPONSE from PGM=IKJEFT01 I think you 
need to give us some more information.  I'm not familiar with XQUERY and it's 
quirks.  What kind of response are you expecting?  Is the output dataset empty?
 
That said, it's been so long since I've run anything in batch without REXX I 
don't recall if vanilla TSO reports non-zero return codes.
 
You may want to find/tweak a mainframe version of REXXTRY, and add PARM=REXXTRY 
to your EXEC.  Be sure to have a SYSEXEC DD for the library where you put 
REXXTRY.  In addition to return code reporting REXXTRY let's you use most REXX 
features.  E.g., you can set a variable to the DSN and/or VOL if the change 
between runs. Put your commands in quotation marks, and follow REXX syntax.
 
It looks like you might benefit from writing a batch REXX EXEC to do that work.
 
See these documents for more information.
 
  e741ba69-356d-4ffc-84dd-91ae1e883fb1.pdf
<https://drive.google.com/file/d/1A3ZvcyAgh3reW0x0bGvSnkeB_7FXZNgX/view?usp=drivesdk>
 
  Modernizing z/OS Batch Processing
<https://docs.google.com/document/d/1vwE-dAyxHg-PEXAZl1Odbf6-QWwA22a1GoSPlkJL5rI/edit?usp=drivesdk>
 
 
 
 
 
 
On Sun, 24 Mar 2019, 8:43 pm Jason Cai,  wrote:
 
>
> Hi all
>
>   We issue a lot of TSO  commands ( XQUERY NP2XRE 
> DATASET('XXX.TST')
> DISP(MOD) VOLUME(BJ2817) DETAIL )
>
> by PGM=IKJEFT01 .The sample is blow:
>
> //S1EXEC PGM=IKJEFT01,REGION=0M
> //SYSTSPRT DD SYSOUT=*
> //SYSPRINT DD SYSOUT=*
> //SYSTSIN  DD *
>  XQUERY NP2XRE DATASET('XXX.TST') DISP(MOD) VOLUME(BJ2817) DETAIL  
> XQUERY NP2XRE DATASET('xxx.TST') DISP(MOD) VOLUME(BJ2897) DETAIL  
> XQUERY NP2XRF DATASET('xxx.TST') DISP(MOD) VOLUME(BJ2917) DETAIL
>
>
> We found there are just  part of this commands responsed.
>
>
>
> Any thoughts/comments/suggestions would be greatly appreciated
>
>
>
>
>
> Best Regards,
> Jason Cai
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
 
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
 

--
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: How many asterisks to change a lightbulb?

[Barry Merrill]

Construction sites in Ireland can not use the standard 220v tools,
they had to set up a 110 converter and network.
Battery powered hand tools have reduced that need somewhat.


Barry Merrill




-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Smith
Sent: Friday, March 8, 2019 6:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How many asterisks to change a lightbulb?

Lol... The US is in the midst of a craft beer craze, so you may be able to find 
some acceptable brews.  I judge beer on how closely it resembles a glass of 
Coors at 34F, so you'll need others for advice on that.

As for power, an accident with 110V is less likely to invoke a life insurance 
payout rather than 220V (which we do generally have available for stoves, 
dryers, HVAC, etc.).

I foolishly bought a clock-radio in Germany because it was the only one I found 
with a 24-hour display.  Turns out the clock time was based on the power 
frequency (which reasonably affordable adapters cannot convert) :-(.

Sorry, but it is actually Friday now ;-).

sas

On Thu, Mar 7, 2019 at 6:58 PM Wayne Bickerdike  wrote:

> Sorry Jesse,
>
> I lived in the USA for five years and found that Edison screw light 
> bulbs get stuck in the socket, plus there is no recommended torque 
> setting for installing same.
>
> Many odd things about your electricical standards:
>
> No isolating switch on wall sockets. Love the flash as you plug things in.
>
> Lights? What lights? Most places we rented just assume you will 
> provide uplighters and one of them plugs into the only socket in the 
> room that is connected to the switch at the entry.
>
> 110V? Great unless you want real power. Three-phase needed for any grunt.
>
> At least Tesla won over Edison and you went AC...
>
> It's Friday and I've packed all my converter gadgets for Share in Phoenix.
>
> If you are there, I'll buy you a beer. I'm sure your beer tastes the same.
>
> Wayne
>
>

--
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: Jes2 Initiator number

[Barry Merrill]

In 2004, MXG Change 19.269 provided an IEFU84 exit that captures
and moves the Initiator Number and Initiator Number into the
SMF 30 Subtype 1, and MXG type 30 processing picks them up.

I have no recent confirmation that exit code runs but I also
have no recent confirmations that it's in use anywhere.

Barry


Herbert W. “Barry” Merrill, PhD
President-Programmer
Merrill Consultants
MXG Software
10717 Cromwell Drive
Dallas, TX 75229
www.mxg.com
ba...@mxg.com






-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Cieri
Sent: Tuesday, August 7, 2018 2:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Jes2 Initiator number

Is the JES2 initiator number that runs a job recorded in any SMF records??

The only "audit" trail that I can find is the $HASP373 message when a job is 
started.

I would appreciate any pointers that anyone can provide.
Thanks
Tony

--
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: Weird thought for ISPF enhancement

[Barry Merrill]

I left z/OS as a development platform, going to Windows in 1996
for MXG Software totally because of the loss of everything under
TSO if I didn't hit enter every 45 minutes.

However, it is still the primary QA test platform, but using
batch instead of TSO.


Herbert W. "Barry" Merrill, PhD
President-Programmer
Merrill Consultants
MXG Software
10717 Cromwell Drive
Dallas, TX 75229
www.mxg.com
ba...@mxg.com






-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Tuesday, June 5, 2018 3:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Weird thought for ISPF enhancement

Thanks. I will give that sort of thing a try.

I *still* like John's weird thought. I work from a home office. I tend to be
a little loose with the demarcation between work and not work. Sometimes I
get up from my PC. Sometimes I come back in 20 minutes. Sometimes I do not.
I like that whether I am gone for ten seconds or ten hours, I find Windows
right where I left it. It would be nice if ISPF were right where I left it.
(I understand the resource and security advantages of a forced logoff.
John's weird thought would make that logoff more transparent.)

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jerry Whitteridge
Sent: Tuesday, June 5, 2018 1:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Weird thought for ISPF enhancement

I use a rexx exec to "script" all my sessions every time I logon.

/* REXX */
/* TRACE I */
ADDRESS ISPEXEC
"SELECT PGM(ISPSTRT) PARM(SCRNAME SDSF2 PERM; =SDSF; SWAP LAST) "
"SELECT PGM(ISPSTRT) PARM(SCRNAME EDIT1 PERM; =2; SWAP LAST)"
/*ELECT PGM(ISPSTRT) PARM(SCRNAME EDIT2 PERM; =2; SWAP LAST)" */ "SELECT
PGM(ISPSTRT) PARM(SCRNAME MYDS PERM; REFOPEND; SWAP LAST)"
"SELECT PGM(ISPSTRT) PARM(SCRNAME BROWSE1 PERM; =1; SWAP LAST)"
"SELECT PGM(ISPSTRT) PARM(SCRNAME TSO PERM; =6; SWAP LAST)"
"SELECT PGM(ISPSTRT) PARM(SCRNAME DSLIST PERM; =3.4; SWAP LAST)"
"SELECT PGM(ISPSTRT) PARM(TSO WORKPL)"
EXIT(0)


I call this SESSTART and simply do a TSO SESSTART as soon as I am at the
Primary option menu after logging on. (In 2.2 or above I believe this can be
done automagically).


Jerry Whitteridge
Delivery Manager / Mainframe Architect
GTS - Safeway Account
602 527 4871 Mobile
jerry.whitteri...@ibm.com

IBM Services

IBM Mainframe Discussion List  wrote on
06/05/2018 12:33:59 PM:

> From: Charles Mills 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 06/05/2018 12:34 PM
> Subject: Re: Weird thought for ISPF enhancement Sent by: IBM Mainframe 
> Discussion List 
>
> I really like it. I have an associate who sets up some elaborate 
> configuration of SPLITs. He is always selling me on the benefits. I 
> see the benefits, but one of the reasons I do not follow suit is 
> because of the need to re-do it on every logon. If I could just have 
> ISPF automatically restore my previous setup it would be great.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU ] 
> On Behalf Of John McKown
> Sent: Tuesday, June 5, 2018 11:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Weird thought for ISPF enhancement
>
> I'm short of sleep ... again. When I came to work this morning, my 
> Chrome browser was "dead". When I restarted it, it prompted me with a 
> message asking if I wanted to restore all the pages I had been on.
>
> So, what occurred to me was, "Wouldn't it be nice if ISPF could do 
> something like that." Now, ISPF doesn't really die often. But I think 
> it would be a nice feature if there were a new ISPF command, perhaps 
> called something like "SAVELEAVE" or HIBERNATE or whatever. This 
> facility would let you logoff for the day, optionally SAVEing any 
> changes if you're in EDIT or one or more screens. When you come in the 
> next day, ISPF would
give
> you an option to restore all your screens. Yes, there are problems 
> about restarting an ISPF application, but basically you could only 
> issue the above command at certain times, just like you can only SWAP 
> or SPLIT,
when
> you're in an DISPLAY verb. What I envision for an ISPF application is
that
> it would get a special RC from the ISPF DISPLAY verb which would 
> indicate "user wants to leave, checkpoint or abandon your processing". 
> The application could then only do something like ISPF CHECKPOINT 
> which would basically return to ISPF and ISPF would terminate the 
> application.  The application would need to save its non-ISPF 
> environment (close files,
etc)
> before it issued the CHECKPOINT. When the user gets back into ISPF, 
> the application is restarted at the next instruction after th

Re: OA53355 - USERKEY COMMON MIGRATION SUPPORT

[Barry Merrill]

Change 35.212  Support for SMF 30 User Key CSA Audit Enhancements adds
VMAC30 new SMF30_RAXFLAGS to TYPE30_1, TYPE30_V, TYPE30_4 and
Sep 28, 2017   the TYPE30_5 datasets.  This code change has been in MXG
Feb 28, 2018   35.09 and later, but this change text replaced previous
   "Reserved Change" on Feb 28, 2018.  This field was added
   by APAR OA53355, but will only be needed thru z/OS 2.3,
   as User Key Common Storage usage support ends there.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jousma, David
Sent: Tuesday, April 24, 2018 1:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: OA53355 - USERKEY COMMON MIGRATION SUPPORT

So, has anyone written a SAS/MXG program to read through these SMF30 records
yet, that they would care to share?   Seems to be the easiest method to run
through the daily data to determine who is using USER Key common?   I see
the slip noted in the APAR, and I could go that route, but still have to
look through GTF data it seems.

I know I have one long running home-grown system task for sure using it, but
what I do not know if there are any short lived usage.   We are already
working on retiring the home-grown system task.

SA38-0667-XX  z/OS MVS System Management Facilities (SMF)
  Add the following new SMF Type 30 record fields in the
  Storage and Paging Section:
  Offsets  NameLength  Format...
  178  B2  SMF30_RAXFLAGS  1   binary...
  Description
  Bit   Meaning
  0 When SMF30_USERKEYCOMMONAUDITENABLED is on,
auditing of user key common storage usage attempts
enabled for this step/job.
SMF30_USERKEYCSAUSAGE, SMF30_USERKEYCADSUSAGE and
SMF30_USERKEYCHANGKEYUSAGE are only applicable when
this flag is on.
  1 When SMF30_USERKEYCSAUSAGE is on, attempts were made
to obtain user key CSA storage for this step/job.
This bit is only valid when
SMF30_USERKEYCOMMONAUDITENABLED is on.
Once this bit is set on for an interval record, this
bit will also be set on for all subsequent interval
records for this step.
Once this bit is set on for a job interval or step-end
record, this bit will also be set on for step-total
and job-end records.
  2 When SMF30_USERKEYCADSUSAGE is on, attempts were made
to create a user key CADS for this step/job.
This bit is only valid when
SMF30_USERKEYCOMMONAUDITENABLED is on.
Once this bit is set on for an interval record, this
bit will also be set on for all subsequent interval
records for this step.
Once this bit is set on for a job interval or step-end
record, this bit will also be set on for step-total
and job-end records.
  3 When SMF30_USERKEYCHANGKEYUSAGE is on, attempts were
made to change the key of common ESQA storage to a user
key (via CHANGKEY) for this step/job.
This bit is only valid when
SMF30_USERKEYCOMMONAUDITENABLED is on.
Once this bit is set on for an interval record, this
bit will also be set on for all subsequent interval
records for this step.
Once this bit is set on for a job interval or step-end
record, this bit will also be set on for step-total
   and job-end records.



_
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

This e-mail transmission contains information that is confidential and may
be privileged.
It is intended only for the addressee(s) named above. If you receive this
e-mail in error, please do not read, copy or disseminate it in any manner.
If you are not the intended recipient, any disclosure, copying, distribution
or use of the contents of this information is prohibited. Please reply to
the message immediately by informing the sender that the message was
misdirected. After replying, please erase it from your computer system. Your
assistance in correcting this error is appreciated.




--
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: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Barry Merrill]

In 1975 there was a BOF, Bird's of a Feather Session on Year 2000 Concerns
at the SPRING SHARE meeting, as I recall.  BOF's were spontaneous evening
meetings posted/scheduled usually that day.

Barry 


Herbert W. “Barry” Merrill, PhD
President-Programmer
Merrill Consultants
MXG Software
10717 Cromwell Drive
Dallas, TX 75229
www.mxg.com
ba...@mxg.com



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, April 20, 2018 5:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware 
(nextgov.com)

On Fri, 20 Apr 2018 19:25:54 +, Lester, Bob wrote:
>
>I agree with both you and Gil.  But, how many programmers in the 60s, 70s, 
>even 80s were thinking about Y2K?  Sure, the really good ones were, but what 
>about the other 80%?
>
>and, Y2K came off without a hitch...(FSVO - "hitch")


>-Original Message-
>From: IBM Mainframe Discussion List Porowski, Kenneth
>Sent: Friday, April 20, 2018 1:20 PM
>
>That was due to lack of foresight by the programmer not due to the age of the 
>system.
>
True in the sense that it affected one-year-old computers as much as older 
computers running th same software.

I'm disappointed that this thread has so much focused on Y2K which I meant only 
as an extreme example.  Things change.  Y2K was only more precisely forseeable.

Increasing complexity of the tax code requires new logic.  Inflation and rate 
escalation may have made some data fields inadequate in size.  E-filing 
requires network interfaces and code to support them and causes the one-day 
spike in workload.  I gather from these fora that COBOL is not comfortably 
suited to TCP/IP.  IBM bet that SNA/VTAM could crush TCP/IP and customers were 
the losers.  IBM bet that EBCDIC could crush ASCII and customers were the 
losers.  And customers bet that COBOL skills would remain in the forefront of 
availability.

-- gil

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

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

Re: VSE timeline [was: RE: VSAM usage for ancient disk models]

[Barry Merrill]

You said: 

"The 3370s had a manufacturing fault that caused HDA failures. 
A good friend was an IBM CE and he told me that it was caused 
by contaminated lubricant."

In about 1975, I recall Roger Buchanan, an IBM CE originally from Australia,
described an IBM Disk Error problem he had just recently resolved, and I
think it was with the first European delivery of 3330s.

Apparently the new drives had been stored in several warehouses worldwide,
including one in Germany, awaiting the GA for shipment, and when those
first shipments went out, one-half of all of the European-stored drives
failed, with no other failures reported from any other warehouse.

Fortunately, IBM kept meticulous records of exactly where the drives had
been stored, so it only took a few days of failures to determine that 
all of the failed drives had been stored on the perimeter of the room,
and there were no failures for the interior stored devices.
By then, all of the failed devices had been replaced from other warehouses.

It took somewhat longer to determine the actual cause.
The walls of the storage room had been painted in a silicon-based paint,
and that silicon had leeched (?) into the silicon substrate of those
devices near the silicon wall (platters or electronics??).

Barry


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694



 


 



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Wayne Bickerdike
Sent: Wednesday, January 17, 2018 5:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VSE timeline [was: RE: VSAM usage for ancient disk models]

I remember the 3310. IBM called them "piccolo" drives because of the noise the 
actuators made.

We received a bunch of these as replacements for faulty 3370s. That was back in 
1981 when I was working at ICI Petrochemicals in the UK.

The 3370s had a manufacturing fault that caused HDA failures. A good friend was 
an IBM CE and he told me that it was caused by contaminated lubricant.

It only affected drives manufactured at the plant in Germany. US drives weren't 
affected.

That was my first foray into DOS/VSE and FBA architecture.

We were running on a 4331 box, it was tiny and we ran ADABAS and CICS with a 
bunch of batch programs that built a bill of materials reporting system.

Batch runs took 24 + hours and the particular technique we used to drive the 
totals up the hierarchy destroyed those 3370s. (Lots of VSAM inserts and CI/CA 
splits).

We optimised the solution by using ADABAS which did work better than VSAM at 
the time.

Pretty sure that VSE/AF was a release too.

On Thu, Jan 18, 2018 at 5:28 AM, Seymour J Metz <sme...@gmu.edu> wrote:

> Thanks. I was really hoping for something that listed all of the 
> players, with dates.
>
> VSE/AF was an add-on DOS/VSE package, just as MVS/SE was an add-on, 
> but I don't recall anybody saying "I'm running OS/VS2 R3.7 with 
> MVS/SE" or "I'm running OS/VS2 R3.8 with MVS/SE" instead of the 
> shorter "I'm running MVS/SE" or "I'm running MVS/SE2". Likewise with VM/SE 
> and VM/BSE.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on 
> behalf of Farley, Peter x23353 <peter.far...@broadridge.com>
> Sent: Wednesday, January 17, 2018 1:16 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: VSE timeline [was: RE: VSAM usage for ancient disk models]
>
> On this Wikipedia page, notes #44 and #45 lead to IBM z/VSE history 
> pages that may tell you what you want to know.
>
> https://secure-web.cisco.com/1Hxni8z1xE6vDmveRBopjI3Vzv4qg9
> VQ9eZGrH7t2axlv2TXRuKnDcewtJL-hrpi8jwK3-GxrA-
> 2iIMOvZDRBBfUNxKH2YcS14FFnmmhJH8BilUDJ1_2fI_5ME-
> 1hcCiY4dtKk8BTHa4OU6MfD7om1snenBWocvMGhl9GvOLU0_SOumoC5h-SVpLXZF_fC_
> aZLNzcOoQkWOHCDg6EhiG_kuy613a7e10fUIKzh-OapHJjXeZgVzPmkE1JIrW3eqtWAaxH
> eHFBht9WMWu5HxrN0rT_G2I-jEIzGTcNKtmOQfe1k--Q0UIKlGX2P1YoZJPSn6SKoEFiqv
> 9AD qG0PB3IvtsFsaIpaeCFoMMwXzsHPbebyeNDS7pKAq0_bLLcvaHD8dg6P2PU_
> hyO9MaXHylVHJzPZYhoUg3Uqk6r93PuIyH8nr2wio5V00QSoeYBZEzu/
> https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FHistory_of_IBM_
> mainframe_operating_systems#DOS/VS
>
> 1980's VSE history: https://secure-web.cisco.com/
> 1mhCrVwIL6XNHIiS5zTkFhpBby8bw8liiRCkscsxbarX123Dg5jOSVKmKsH7
> ad9EfIz7qIm2VVjm9Z7niqX7VrOYwox2dnKpLjSm1a4bqN28BrF0nUCxpLYq
> EgyI9sWzR8x15GQT8mhNnr7iBxhHfQHD3hNKOYFygabIef1J9hcGY0ePFJPB
> RCtLVtsFarc387G5z2gY2lEqN7e-2ZYPN7cE2fKe6SWiDdlMkdc6vKiZYN
> dLbLrWHW0yzZ8YEjssi7Ek0bjZJYXIpSG6BW49F2LPvg9d6OTqa

Re: How to find what performed an OMVS unmount?

[Barry Merrill]

MXG creates a SUBTYPE for the many SMF records that contain a logical subtype 
that is not contained in the standard SMF Header, including fields like the
SMF 80 RACF EVENT Code and the SMF 100-102 DB2 IFCID value.

Barry


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Robert S. Hansel (RSH)
Sent: Thursday, December 28, 2017 6:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to find what performed an OMVS unmount?

Peter,

The type 80 record doesn't have subtypes. 55 is an event code, and event code 
is a field in the 80 record. I do not know if MXG is aware of and can select 
records based on type 80 event codes. If your RACF team converts SMF 80 records 
to text format using RACF's SMF unload utility, you can try searching the 
unload file for UMNTFSYS events - the text equivalent of event code 55.

Various RACF auditing options determine whether such an event would be logged, 
and such options may not have been in effect when the event occurred, hence no 
record.

Since the NOTYPE ranges do not exclude 80 records, you are correct that they 
are being collected. Also look for SUBSYS settings that might be excluding them 
for certain subsystems.

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc. *** Celebrating our 25th Year ***
617-969-8211
www.linkedin.com/in/roberthansel
http://twitter.com/RSH_RACF
www.rshconsulting.com

-Original Message-
Date:Wed, 27 Dec 2017 13:03:41 -0600
From:Peter Ten Eyck <peter.tene...@americannational.com>
Subject: Re: How to find what performed an OMVS unmount?

Thanks for the suggestion on this topic. I have discovered that the LPAR that 
this un-mount occurred on does not cut type 92 (USS) records so I will be 
unable to use them to figure what un-mounted my file.

Setting: SYS(NOTYPE(16:19,62:69,92)

With the help of MXG staff, I was able to run a MXG report looking for type 80 
(RACF) sub type 55 records, I did not find any. To me this means that either 
there were no un-mounts during the time period of the input or no sub type 55 
records are cut. Is the above setting what controls the sub type records cut? 
Type 80 is not excluded so it’s being cut, is the default all 80 sub types?

--
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: How to find what performed an OMVS unmount?

[Barry Merrill]

The site's MXG job found the SMF 92 records were not enabled, and there were
no RACF UNMOUNT 55 records found.

Barry


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Andrew Rowley
Sent: Saturday, December 23, 2017 12:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to find what performed an OMVS unmount?

On 23/12/2017 02:53 AM, Peter Ten Eyck wrote:
> That is what makes me think if there is an answer to be found, it may be in 
> the type 92 records. The only tool I think I have to do this in MXG. I am not 
> very proficient with that tool; it’s going to take me awhile to figure out 
> how to generate a report of all the mount and un-mounts in USS for a specific 
> period of time.
You are welcome to download a 30 day trial of EasySMF. The z/OS Unix Filesystem 
Activity report probably has what you are looking for.

https://www.blackhillsoftware.com/easysmf/

Andrew Rowley

--
Andrew Rowley
Black Hill Software
and...@blackhillsoftware.com

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

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

Re: How to find what performed an OMVS unmount?

[Barry Merrill]

Yes, MXG supports the all subtypes of the SMF type 92 records;
you'll may want the current MXG Version as IBM made recent changes 
in those records, but primarily for z/OS 2.3.

Barry


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694





-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Ten Eyck
Sent: Wednesday, December 20, 2017 12:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to find what performed an OMVS unmount?

Thanks. I am researching what software I have available to work with those 
records. I am wondering if I can use MXG to go against those type 92 records 
and find what performed the un-mount.

--
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: Possible Debug issue

[Barry Merrill]

The IEF032I Joblog Message

IEF032I STEP/SAS9/STOP  2017344.2055
CPU: 0 HR  00 MIN  00.67 SECSRB: 0 HR  00 MIN  00.02 SEC
VIRT:   912K  SYS:   292K  EXT:46616K  SYS:11788K
ATB- REAL:  1044K  SLOTS: 0K
 VIRT- ALLOC:  11M SHRD:   0M

has the REGION SIZE allocated in the sum of the EXT + SYS  = 46616K+11788K=
58404K = 57 MegaBytes

Barry


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Lizette Koehler
Sent: Wednesday, December 13, 2017 9:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Possible Debug issue

Depending on you IEFUSI or other functions used to control region size, you
may not be getting what you think 0M gives you.

If you try the suggestion of 2000M for region and rerun the job, what do you
get?

If you have an ACTRT exit in your shop - it may provide the virtual storage
map at step end. There you should the Requested/Below/above/ and so forth of
storage allocation for the step.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Savor, Thomas (Alpharetta)
> Sent: Tuesday, December 12, 2017 11:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Possible Debug issue
> 
> On this particular test that got all the storage error 
> messages..region was set to 0M
> 
> Thanks,
> 
> Tom Savor
> Software Developer, Sr
> FRMS-SCM
> Fiserv
> Office:  678-375-1307
> Mobile: 404-660-6898
> Fax:  678-375-3280
> www.fiserv.com
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Peter Hunkeler
> Sent: Wednesday, December 13, 2017 1:14 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: AW: Re: Possible Debug issue
> 
> >Debug Tool and Fault Analyzer seem to take a huge amount of memory 
> >when
> working with COBOL 5.  Try setting REGION=2000M.
> 
> 
> What release of z/OS managed to move the whole common area above the bar?
> Seriously, 2000M will probably never be available in the private 
> region. But if you want to see how much you need to be able to debug, 
> within the maximum available, specify REGION=0M.
> 
> 
> --
> Peter Hunkeler
> 
> 
> 
> 
> 
> --
> Peter Hunkeler

--
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: Since it's Friday

[Barry Merrill]

Button 287 "VSAM is the COBOL of Access Methods" was by Tom McSloy at GUIDE
in 1975.  And COBOL programmers at the time thought that was a compliment!

www.mxg.com/thebuttonman/search.asp 

Merrilly yours,

Barry Merrill


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Tuesday, December 5, 2017 7:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Since it's Friday

I'm not so "young" to remember that, however I vaguely remember I read some 
VSAM book (bought for many $$$). The book was awfully outdated, so I learned 
mostly VSAM history and obsolete features. It was ~13 years ago, but I would 
bet VSAM was born in 1974.

--
Radoslaw Skorupka
Lodz, Poland






W dniu 2017-12-05 o 09:19, Wayne Bickerdike pisze:
> VSAM was no later than 1975. I was in a PL/I class at Sudbury in 1975.
> Happened to be the week England beat Cyprus at Wembley 5-0 and Malcolm
> MacDonald scored all 5 goals.
>
> Anyway, our teacher at Sudbury asked this question:
>
> "Why is VSAM like a cow in the middle of a meadow".
>
> Answer:
>
> "They are both outstanding in their field".
>
> 16 April 1975: England's Malcolm Macdonald scores five against Cyprus
>
> Funny how things stick in your memory.
>
> We were still ISAM many years later.
>
> On Tue, Dec 5, 2017 at 9:00 AM, Seymour J Metz <sme...@gmu.edu> wrote:
>
>> ICF came in with DF/EF, which preceded MVS/XA.
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>>
>> 
>> From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf
>> of Mike Schwab <mike.a.sch...@gmail.com>
>> Sent: Monday, December 4, 2017 4:29 PM
>> To: IBM-MAIN@listserv.ua.edu
>> Subject: Re: Since it's Friday
>>
>> I think CVOL / VSAM catalogs in MVS was version 1.  ICF catalogs
>> introduced during XA switchover period is version 2.
>>
>> On Mon, Dec 4, 2017 at 8:56 AM, R.S. <r.skoru...@bremultibank.com.pl>
>> wrote:
>>> W dniu 2017-12-01 o 21:43, Pew, Curtis G pisze:
>>>> This is just a curiosity question, but I’ve wondered about this.
>>>>
>>>> The JCL reference says:
>>>>
>>>> All temporary data set names begin as follows:
>>>> SYSyyddd.Thhmmss.RA000.jjobname
>>>>
>>>> Does anyone know the story behind the ‘RA000’ part? It seems unnecessary
>>>> and arbitrary.
>>>>
>>> Well, we used to answer "Frankie did this and he said >> do't change it<<
>>> but Frankie died..."
>>>
>>> BTW: almost every LISTCAT output contains "VERSION: 2" statement. Why
>> it's
>>> 2?
>>>
>>>
>>> --
>>> Radoslaw Skorupka
>>> Lodz, Poland
>>>
>>>


==


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

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

 mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.

Re: SAS - DB2 conversion to Java

[Barry Merrill]

We have many MXG users who have moved their SAS Processing to Linux or Windows,
where only a Workstation license may be needed, and there is no download of the 
SMF data file; the SAS ftp access method reads the z/OS data and only the output
SAS datasets need disk space on the ASCII platform.

And that eliminates the risk and cost of reprogramming.

I'd also be VERY concerned about the execution time if your applications are
high volume under Java versus under SAS.

And if the reason for DB2 is for your DB2 DBAs that only speak SQL, they
can use the free PROC SQL and issue SQL calls and reports to their heart's
content.

And you have the full power of SAS ODS to create output in HTML, EXCEL, etc.

With the already working and tested SAS language program unchanged.


Merrilly THANKSGIVING TO ALL, 

Barry Merrill


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Munif Sadek
Sent: Thursday, November 23, 2017 1:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SAS - DB2 conversion to Java

Hi listers

We are planning to take-up an POC for converting SAS (including SAS - DB2 ) 
programs to Java  in order to save on SAS licencing cost and mainframe GCP 
MSU$.  Can someone Please provide any  pointers in the right direction or share 
his or  her experience, Please. 


regards Munif

--
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: Odd SMF 30 data within IEFACTRT

[Barry Merrill]

All or almost all DB2 data can contain length=0 as documented 
in DB2 Maclib SDSNMACS members, for one example below.

Barry


./   ADD   NAME=DSNDQWA0,SSI=24351827
*   %DCL DSNDQWA0_LIST CHAR EXTERNAL;   0001
*   %IF DSNDQWA0_LIST ^= '' %THEN/* DSNDQWA0_LIST IS SET TO  */ 0002
* %GOTO QWA0_LIST_ON;/*YES FOR THE LISTING   */ 0003
*   @LIST PUSH; 0004
*   @LIST OFF;  0005
*   %QWA0_LIST_ON:; 0006
*   0007
*   %GOTO PLSPART_DSNDQWA0; 0008
*/*/0009
*/* MACRO-NAME = DSNDQWA0 */0010
*/* DESCRIPTIVE-NAME = DB2 SELF DEFINING SECTION MAPPING MACRO*/0011
*/* FOR ACCOUNTING IFCID=0003 */0012
*/*Licensed Materials - Property of IBM   */0013
*/*5615-DB2   */0014
*/*(C) COPYRIGHT 1982, 2013 IBM Corp.  All Rights Reserved.   */0015
*/*   */0016
*/*STATUS = Version 11*/0017
*/* FUNCTION = MAPPING MACRO FOR DB2 ACCOUNTING SELF DEFINING */0018
*/*SECTION FOR IFCID=0003 */0019
lines deleted
*/*/0055
0057
*/**IMPORTANT PARSING INFORMATION*IMPORTANT PARSING INFORMATION 0058
* * 0059
* The length field for any (offset,length,number of data sections)* 0060
* triplet can legally be zero with a non-zero offset.  This indicates * 0061
* this section is a varying length repeating group. A varying * 0062
* length repeating group is a series of related data blocks with  * 0063
* differing lengths. This is typically, if not always, the result of  * 0064
* varying length long name fields in the data block.  * 0065
* * 0066
* In order to parse a varying length repeating group, the following   * 0067
* steps should be taken:  * 0068
* 1. Follow the offset pointer to find the first member of the group. * 0069
* 2. Each member will be mapped as follows:   * 0070
*<2 byte member length>  * 0071
* * 0072
*The length of the first member will be in the 2 bytes pointed* 0073
*to by the offset pointer.  It is important to note that the  * 0074
*data section for the first member will start 2 bytes past the* 0075
*offset pointer.  * 0076
* 3. Subsequent members can be found by advancing the pointer * 0077
*(length of current member + 2 bytes) forward.  These members * 0078
*will also be formatted as <2 byte length>.  * 0079
*Again, it is important to note that the data section starts 2* 0080
*bytes past the beginning of the member.  * 0081
* 4. The number of members in the repeating group will be held in * 0082
*the corresponding 'number of data sections' field in the * 0083
*self-defining section.   * 0084
* * 0085


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of DanD
Sent: Monday, November 6, 2017 5:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Odd SMF 30 data within IEFACTRT

Thank you Berry,

"As noted, the Length value of zero is now used to indicate that the actual 
length is in the first two bytes at the offset, if COUNT is non-zero."

Do you know of a field where this is the case?   I've never seen that.

Thanks again,
Dan

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

Re: Odd SMF 30 data within IEFACTRT

[Barry Merrill]

It is documented for many newer SMF records that the COUNT field is the
sole indicator that there are in fact these segments in this record.
The OFFSET seems always to be busy, and the value of the location of
the next triplet, even when this is the last triplet.

As noted, the Length value of zero is now used to indicate that the
actual length is in the first two bytes at the offsed, if COUNT is
non-zero.

Barry


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of DanD
Sent: Monday, November 6, 2017 2:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Odd SMF 30 data within IEFACTRT

Thanks everyone.

I WILL check all 3 fields for zeros in the future.
It's still odd that the 1st record has an offset and length but the count is 
zeros...

"Here's the section your looking for ... it's this big ... and there are NONE"  
what? ;-)

Dan

--
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: SUBSYS= ?

[Barry Merrill]

For what it might be worth, considering free advice may only be worth the price,
the below code is used in MXG Software to decode JCTJOBID into TYPETASK and 
JESNR, and
it tests for all SUBSYS names I have ever seen in any SMF record, which are 
used only
to prevent warning messages about known records that don't have a valid 
JCTJOBID value
to decode. 

Barry  


/* COPYRIGHT (C) 2002,2017 MERRILL CONSULTANTS, DALLAS, TEXAS, USA */
 /* LAST UPDATED: NOV  4, 2017.  CHANGE 35.252. */
 /* THIS ROUTINE EXPECTS JCTJOBID AND JOB AS 8-BYTE CHARACTERS, */
 /* AND SUBSYS AS A 4-BYTE CHARACTER AS INPUT.  */

 /* JCTJOBID OF ONE LETTER AND 7 DIGITS EXIST, BUT THE MAXIMUM  */
 /* JESNR IS 99 BECAUSE THE 1ST WHEN SEVEN IS ALWAYS ZERO.  */

 /* IT CREATES THE 4-BYTE CHARACTER TYPETASK AND NUMERIC JESNR  */
 /* VARIABLES TYPETASK AND JESNR NEED TO BE LABELED IN INVOKER. */

 /* IT IS %INCLUDE-D AFTER JCTJOBID AND SUBSYS EXIST.   */

 TYPETASK='';
 JESNR=.;
 IF SUBSYS=''  THEN SUBSYS=''; /*EARLY ASIDS,TMNT */
 IF JCTJOBID=JOB OR (JCTJOBID LE ' ' AND SUBSYS='STC')
   OR (JCTJOBID EQ ''X AND SUBSYS='SMS')
   OR (JCTJOBID EQ 'MSTR' AND SUBSYS='SMS')
   OR (JCTJOBID EQ 'INIT' AND SUBSYS='SMS') THEN DO;
   JESNR=.;
   TYPETASK='STC';
 END;
 ELSE DO;
   IF INPUT(SUBSTR(JCTJOBID,2,7),?? 7.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,2,7),?? 7.);
 TYPETASK=SUBSTR(JCTJOBID,1,1);
   END;
   ELSE IF INPUT(SUBSTR(JCTJOBID,3,6),?? 6.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,3,6),?? 6.);
 TYPETASK=SUBSTR(JCTJOBID,1,2);
 /* THE PRINTWAY SMF 6 RECORDS HAVE PSNN */
   END;
   ELSE IF INPUT(SUBSTR(JCTJOBID,4,5),?? 5.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,4,5),?? 5.);
 TYPETASK=SUBSTR(JCTJOBID,1,3);
   END;
   ELSE IF INPUT(SUBSTR(JCTJOBID,5,4),?? 4.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,5,4),?? 4.);
 TYPETASK=SUBSTR(JCTJOBID,1,4);
   END;
   IF SUBSYS='TCP ' OR TYPETASK='PS ' THEN TYPETASK='TCP ';
   ELSE IF SUBSYS='TCPE' THEN TYPETASK='TCPE';
   ELSE IF SUBSYS='PSF ' THEN TYPETASK='PSF ';
   ELSE IF SUBSYS='VPS ' THEN TYPETASK='VPS ';
   ELSE IF TYPETASK=:'J' THEN DO;
 IF  SUBSYS='TSO ' THEN TYPETASK='TSU ';
 ELSE IF SUBSYS='JES2' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='JES3' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='STC ' THEN TYPETASK='STC ';
 ELSE IF SUBSYS='OMVS' THEN TYPETASK='OMVS';
 ELSE   TYPETASK='JOB ';
   END;
   ELSE IF TYPETASK=:'O' OR SUBSYS='OMVS' THEN TYPETASK='OMVS';
   ELSE IF TYPETASK=:'G' THEN TYPETASK='JOBG';
   ELSE IF TYPETASK=:'S' THEN TYPETASK='STC ';
   ELSE IF TYPETASK=:'A' THEN DO;
 IF SUBSYS GT '' THEN TYPETASK=SUBSYS;
 ELSE TYPETASK='APPC';
   END;
   ELSE IF TYPETASK=:'T' THEN TYPETASK='TSU ';
   ELSE IF TYPETASK=:'I' AND SUBSYS='STC' THEN TYPETASK='STC  ';
   ELSE DO;
 IF  SUBSYS='STC ' THEN TYPETASK='STC ';
 ELSE IF SUBSYS='TSO ' THEN TYPETASK='TSU ';
 ELSE IF SUBSYS='JES2' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='JES3' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='STC ' THEN TYPETASK='STC ';
 ELSE IF SUBSYS='OMVS' THEN TYPETASK='OMVS';
 ELSE DO;
   IF PRODUCT='' THEN PRODUCT='';;
   IF SUBTYPE=.  THEN SUBTYPE=.;
   IF PRODUCT='PERFMON ' AND SUBTYPE=3 THEN DO;
 TYPETASK='STC';
 SUBSYS='PERFMON';
   END;
 END;
   END;
   IF TYPETASK=' ' THEN DO;
 BADVJESN+1;
 IF BADVJESN LE 2 THEN
   PUT '*** WARNING - TYPETASK NOT DECODED: ' /  +10
   _N_= SYSTEM= ID= SUBTYPE= JOB=
   JCTJOBID= SUBSYS= TYPETASK= JESNR= ;
   END;
   
 END;
  /* END OF MEMBER VGETJESN - GET JESNR AND TYPETASK FROM JCTJOBID */



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Monday, November 6, 2017 10:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SUBSYS= ?

Throughout this thread, I've been haunted by a dim memory of some SUBSYS action 
in the distant past. We have not had any in-house SUBSYS dependencies for 
decades, so I did not pay very much attention. 

Did IBM announce long ago that SUBSYS was being deprecated? If so, that might 
explain the dearth of doc. If not, then never mind. 

.
.
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 Charles Mills
Sent: Monday, November 06, 2017 8:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: SUBSYS= ?

I have back to OS/390 V2R8, 1999, on nine CDs. Way pre-PDF. Not there. (Not 
disagreeing with you, just sayin'.)

Perhaps Bitsavers. I don't see it there, but I am not an expert on searching 
Bitsavers.

Perhaps a reader here has an MVS manual they would 

Re: MSU Actual

[Barry Merrill]

RMF III is a separate part of IBM's RMF, writing to its own VSAM files;
it does not write SMF records by itself.  Especially exploiting the
1 minute interval, it is a powerful tactical tool to find out what
happened, while RMF I (SMF 70-79) data is more strategic in nature.

Both are invaluable for z/OS systems.

Barry


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Sankaranarayanan, Vignesh
Sent: Wednesday, October 25, 2017 11:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MSU Actual

Thank you Sir. I'm not sure what the current interval is.
Maybe I can suss the rough interval by looking at timestamps in SMF record
type 70 subtype 1?
Would need to find that out and then consider the implications of changing
it to a 1 minute interval recording.

- Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Barry Merrill
Sent: 25 October 2017 20:26
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MSU Actual

The data is captured in RMF III VSAM files, if you run RMF III at 1 minute
intervals.
The VSAM files can be reported from using IBM Reports, or "ADVERTISEMENT"
MXG Software.

Barry



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Sankaranarayanan, Vignesh
Sent: Tuesday, October 24, 2017 10:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: MSU Actual

Hi All,

Is it possible to get the LPAR, MSU Def. and MSU Act from the RMF CPC
Capacity Report, in bulk?
Looking for samples every 1 minute.
Is this captured in any SMF record type?
Is this a sample report, by any chance, in the RMF Spreadsheet Reporter?

Thanks in advance.

- Vignesh
Mainframe Infrastructure


MARKSANDSPENCER.COM

Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us
know and then delete it from your system; you should not copy, disclose, or
distribute its contents to anyone nor act in reliance on this e-mail, as
this is prohibited and may be unlawful.

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

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

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

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

Re: SMF30 EXCP count confusion

[Barry Merrill]

NOPE, EXCP counts in SMF 30 records can be the count of records, or blocks,
or the number of SSCH (Start Subchannel, was SIO) commands or EXCP commands
issued, depending what the Access Method decided to pass into SMF in the 
IFASMFEX exit that accumulates the type 30 EXCP fields.

And zero is a valid value for an access method to send over, e.g. SORTWORKs.


Barry


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Hunkeler
Sent: Monday, September 25, 2017 9:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMF30 EXCP count confusion

SMF manual, Chapter 10 "EXCP Count" seems to clearly state that EXCP counts
are indeed the number of EXCPs executed. Fields SMF30TEP and SMF30TEX are
described as "Total blocks transferred (accumulated EXCP counts).


I would assume that these fields still contain the number of EXCPs executed
and not the number of blocks transferred. IMHO, the number of blocks is
greater or equal to number of EXCPs. 


So, the number of EXCPs is only a relative measure of the I/O done when
comparing multiple runs of the same program using the same I/O attributes
(blocksize, bufno, etc. etc). It is not a direct measure of the abount of
data really transferred.


Am I right, or what am I missing?




--
Peter Hunkeler

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

[Barry Merrill]

It's not exactly what you asked for, but this 1995 Newsletter Note provides
some information on DB2 I/O counts in SMF 42 Subtype 6 records,
MXG dataset TYPE42DS.  
2. It has always been impossible to track DB2 I/O activity (because the
Media Manager thought itself so fast that it was not necessary to
count I/Os!), but now, the TYPE42DS dataset (from type 42 SMF data)
records both interval and close statistics on ALL datasets (not just
those managed by SMS).  As both the DB2 Database and Tablespace or
Indexspace names are contained in the DSNAME in TYPE42DS, you can
analyze DB2 I/O for each tablespace for each DB2 subsystem. The naming
pattern for the DB2 VSAM datasets looks like this:
   DSNAME=subsystem.DSNDBD.database.table
or, written with MXG variable names (from T102S105 dataset):
   DSNAME=QWHSSSID.DSNDBD.QW0105DN.QW0105TN
asQWHSSSID is the DB2 subsystem Name (almost always DB2...)
  DSNDBD   is a constant string for the data component
  QW0105DN is the DB2 Database Name, and
  QW0105TN is the DB2 Tablespace or Indexspace Name.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Wayne Driscoll
Sent: Wednesday, September 13, 2017 2:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DB2

Q1 - Yes
Q2 - No, DB2 performance records report on the physical level, so the DBID an 
OBID, internal 2 byte fields the uniquely identify the space (table or index) 
being accessed is reported on, not the table id, which is a logical construct. 
There are some audit records that contain DB2 table OBID's, but they are only 
captured at the first access of the thread.

Wayne Driscoll
Rocket Software
Note - All opinions are strictly my own.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Beaver
Sent: Wednesday, September 13, 2017 2:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DB2

Are there any DB2 systems level people in the Group?

Is there a SMF DB2 performance record/or just record that contains the name of 
the table(s) being accessed In the DB2 Space

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
 Rocket Software, Inc. and subsidiaries ■ 77 
Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 877.328.2932 
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

--
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: SoftwareXcel Discontinued

[Barry Merrill]

What a NICE thing to say!!

Barry Merrill

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nightwatch RenBand
Sent: Monday, September 11, 2017 12:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SoftwareXcel Discontinued

Again, Barry Merrill shows he is one smart guy.
Few things made me happier than finding a bug in MXG code and seeing my name 
credited for it.  It amazes me that more software companies do not follow his 
model. For the price of a T-shirt, or a few lines on a web page, they could 
have people falling all over themselves to find, report and fix bugs.

--
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: SoftwareXcel Discontinued

[Barry Merrill]

I did that in my three day class, initially handing a 1980 dollar bill for
each typo 
found in my foils, and after a couple of years handing a 5'er for the last
few.

And I could argue that   http://www.mxg.com/codesharks   page is "paying"
customers
who find bugs.

Merrilly yours,

Barry


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Edward Gould
Sent: Thursday, September 7, 2017 8:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SoftwareXcel Discontinued

> On Sep 7, 2017, at 3:08 PM, Jim Mulder <d10j...@us.ibm.com> wrote:
> 
> With regard  to only the last sentence in Gord's comments, those of us 
> in z/OS development who put the bugs into the software don't have 
> anything to do with the IBM offerings for reporting bugs and
> obtaining fixes for the bugs.   So that does not play any part in 
> our decisions about how many bugs to include in the software.   :-)
> 
> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
> Poughkeepsie NY

Jim,

So IBM admits to having bugs in their software? Then you should be paying
the customer to find them for IBM.

Ed


--
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: Identify EAV volume

[Barry Merrill]

Both DCOLLECT and SMF have flags for EAV volumes,
and programs like MXG Software know about them.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jake Anderson
Sent: Wednesday, July 19, 2017 6:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Identify EAV volume

I was trying to understand if there is any kind of assembler program that can 
query on device report saying that it is EAV volume

On 19-Jul-2017 3:38 PM, "Lizette Koehler"  wrote:

> What problem are you trying to solve?
>
> most shops use a stand set of definitions for dasd which comes with 
> specific setting for size of volume.
>
> So if you see it is a 3390 Mod3 you know it will be 3339 cylinders.
> Though you could make  it different, this is what most will recognize 
> as how many cylinders are on a Mod3.
>
> With EAV the type of volume definition is slightly different and IBM 
> has suggested 3390 ModA (3390-A) for EAV.
>
> Then you would specify how large it is (typically larger than a Mod54)
>
> You also need to see that the Mod-A uses a different sizing - it can 
> be up to 255TB in size for one volume
>
> If you do an internet search on
>
> IBM 3390-A EAV
>
> You might find this Share presentation that might help
>
> SHARE 9941 Planning for EAV Migration
>
> Or this
>
> IBM Redbooks | DFSMS V1.10 and EAV Technical Guide
>
> Or this entry
>
> Extended address volumes for CKD - IBM
>
>
> They (and other presentations and links) should help you understand 
> the EAV
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake Anderson
> > Sent: Wednesday, July 19, 2017 1:57 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Identify EAV volume
> >
> > Hi
> >
> > Is there any command to identify if a particular volume series 
> > belongs
> to EAV
> > ?
> >
> > Any commands or macro which can help ?
> >
> > Regards
> > Jake
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

FW: common storage usage question

[Barry Merrill]

My 2003 Newsletter has this note:

29. APAR OW54622 introduced an SQA overflow into CSA condition that
increased CPU time for many STCs over time; the new GETMAIN larger
than FREEMAIN was corrected by APAR OW55360.  It has long been known
that when SQA is too small and expands into the CSA area, path
lengths are dramatically increased; you can detect this condition in
MXG dataset TYPE78VS variables SQAEXPNx.


Unfortunately, I do NOT know if that statement with regard to increased
CPU time due to path length when there is an overflow is still true, and
I can't find the "long known" source.

Barry


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, Kees (ITOPT1) - KLM
Sent: Monday, June 26, 2017 4:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: common storage usage question



> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Pommier, Rex
> Sent: 20 June, 2017 16:12
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: common storage usage question
> 
> Hi all,
> 
> Curiosity question.  Due to some storage issues we've had recently 
> with old 24 bit programs, I am revisiting our common storage 
> configuration - CSA and SQA.  Taking fragmentation into account, it 
> appears that I'm using about 38% of my allocated SQA and about 46% of my 
> allocated CSA.
> So I'm wondering if anybody has a good feel as to what a "good"
> percentage of used versus allocated space for these areas is.  How low 
> can I safely go in free space in these areas if we decide we want to 
> try to eke out an additional MB of below-the-line private?  Our 
> current private size is 11MB.
> 
> 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.
> 
> 

- Usually I check the peaks of the last 6 or 12 months and consider those good 
guidelines, if you don't plan upgrades that might change the picture.
- You can cut SQA to near 100% usage, because it can overflow to CSA, so you 
don't only need 1 free space area.

Kees.

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
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: Counting Tape mount requests

[Barry Merrill]

Or just look at the count of type 21 SMF records created, in your daily
IFASMFDP "Dump" job, to get the total count of tapes dismounted.



Barry


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ravi Gaur
Sent: Monday, June 19, 2017 4:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Counting Tape mount requests

Easily  Tape Mount Monitor (mxg) or looking at VEHSTATS if you have IBM VTS 
solution.

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

TSO Stats Under zOS 2.2

[Barry Merrill]

 

 

From: MXG Software LIST [mailto:mx...@peach.ease.lsoft.com] On Behalf Of
Doug Medland
Sent: Friday, June 16, 2017 10:27 AM
To: mx...@peach.ease.lsoft.com
Subject: [MXG-L] TSO Stats Under zOS 2.2

 

Good morning.  All of our LPARs that have moved to zOS 2.2 have shown a
dramatic increase in the reporting of our TSO response time, especially  P1.
In some cases, P1 was higher than both P2 and P3 response times.  In other
intervals, TSO response was normal across all TSO periods.  After digging
into what might be using our TSO service class I opened a PMR with IBM.  I
had sent an email to some colleagues asking if they've seen this on their
zOS 2.2 systems.  Someone pointed me to the MXG Newsletters (#67) and found
this:

z/OS 2.2 APAR PI69487 corrects the excessive response time for TSO  
   reported in RMF TYPE72GO elapsed time because each SDSF session's   
   elapsed time was included in the elapsed time of completed TSO  
   transactions.  

Some detail from the APAR / PTF (associated with UI44842):  

SDSF V2R2 offloads  some work to a zIIP when  a processor is
available.  As  part of this implementation, SDSF  creates a WLM
enclave during  initialization.  Since  the enclave  is present,
TSO response  time reports will show  that SDSF is running  as a
long transaction with associated high response times.

My IBM PMR came back with more questions so I had added the above comment(s)
to my inquiry.  Closing date on this fix was 21FEB2017.  IBM updated my PMR
with:

The PTF did not become available until April of this year.   
It's part of RSU/1704.  So you would have to be very current to have
this on. I'm glad your guy found this fix, we would have never looked   
for a SDSF bug here. 

As it turned out, this PTF was not applied to our system(s).  TSO response
was actually fine but for sites with TSO SLAs this would hurt. I'm not an
SME on enclaves, and perhaps someone could help me here, but I'm guessing
enclaves running under TSO wouldn't use periods.  This would explain why P1
was often higher than P2 or P3.  Since the availability of this fix was only
a couple of months ago it might be a good idea to check if your sites have
this fix applied.  We've already started scheduling this update on our zOS
2.2 LPARs. 


Regards,

Doug Medland
IBM Global Services
SMI Performance & Capacity MF 
Phone:  (905) 316-1154


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

Re: Mainframe operating systems?

[Barry Merrill]

There was also a TOS for the 360/44 Serial Number 2 at Purdue's
Lab for Ag Remote Sensing, in '64 or '65, and it needed four tape 
drives because the FORTRAN compiler was on four volumes, and it
was real fun to watch my compiles spin those tapes.

About two months later we got the Disk Drive and DOS.

Barry.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: Monday, April 17, 2017 11:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe operating systems?

http://hercules390.996247.n3.nabble.com/What-is-the-Telpar-OS-td17474.html
Pretty sure they got it running.  Fits on 1 track.

On Sun, Apr 16, 2017 at 9:51 PM, Timothy Sipples  wrote:
> I have a few more additions:
>
> 1. These Japanese operating systems are probably worth mentioning:
>
> Hitachi VOS3
> Fujitsu MSP
> Fujitsu XSP
>
> VOS3 and MSP are proven forks of IBM MVS/XA (at least, and likely also 
> MVS/ESA). XSP might be a fork of DOS/VSE. (I'm less familiar with that
> one.) If you want to hang your hat on supported compatibility with 
> real world IBM machines then VOS3 probably wins. As I recall, VOS3 
> officially runs on z800 and z890 machines, at least. Hitachi built the 
> z800 in a collaboration with IBM, and also for its own domestic sales 
> in Japan, so that one is not a great surprise.
>
> To my knowledge, Fujitsu is still nominally in the mainframe business 
> in Japan, and their machines are basically ESA/390 machines. Both MSP 
> and XSP remain ESA (31-bit), as far as I know. Hitachi's Japanese 
> domestic market machines are ESA/390 machines with very modest, 
> non-z/Architecture 64-bit extensions that VOS3 only lightly exploits.
>
> Speaking of related machines, did RCA's operating systems like VMOS 
> and TSOS ever run on IBM System/360 machines?
>
> 2. TCSC's EDOS/VS and EDOS/VSE were interesting forks of DOS/VS Release 34.
> EDOS/VS and EDOS/VSE were compatible with machines that did not have 
> virtual storage support, including System/360 machines. That's why 
> they enjoyed some popularity. NCSC produced a UNIX subsystem for EDOS 
> called PWS, inspired by Coherent UNIX. I'm not sure if NCSC ever made 
> PWS available for IBM DOS/VSE and its successors.
>
> 3. I don't think anybody mentioned IBM's OS/44 and PS/44 yet. Those 
> were operating systems for the System/360 Model 44, a scientific market 
> machine.
>
> 4. I don't think anybody mentioned VM/IX and IX/370 yet, from 
> Interactive Systems Corporation (ISC). Those were different than 
> AIX/370 and AIX/ESA, based on Locus Computing's work. Bell Labs had a 
> UNIX operating system for
> System/370 even before ISC's products, but I don't know much about that.
> MVS OpenEdition was the successor to these efforts, although with yet 
> another, different, much better technology base. MVS OpenEdition begat 
> z/OS UNIX System Services.
>
> 5. Boston University's VPS/VM traced its roots to McGill University's 
> RACS (later RAX, then MUSIC/SP) operating system. As far as I know 
> VPS/VM always ran under IBM's VM, but perhaps that wasn't required. 
> VPS/VM and MUSIC/SP are thus "cousins," one could argue.
>
> 6. TELPAR dates to the early 1970s, but I don't know much about it. I 
> think it's available in open source (PL/360) form, though. Has anybody 
> tried compiling and running it?
>
> 7. VP/CSS, developed by National CSS, was an evolution of CP/CMS. 
> VP/CSS had some efficiency advantages back in the 1970s.
>
> 8. Some people might classify Jan Jaeger's ZZSA as an operating 
> system, a very basic one.
>
> 9. Did the UCSD p-System ever end up on System/370 or System/390 machines?
> It ended up on almost every other processor.
>
> --
> --
> Timothy Sipples
> IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
> E-Mail: sipp...@sg.ibm.com
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

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

Re: Mainframe operating systems?

[Barry Merrill]

I can go further.

The Czech Data center received disk drives, again from Bulgaria,
that were supposed to be ready for production on a Monday,
when the General from the Bulgarian factory was to be there
for the production demonstration, and the drives arrived Friday
morning, with NO technicians, No manuals, and when they opened 
the covers, the Czechs discovered not one cable was connected.

And apparently, under that overall system, you were NOT allowed
to complain, it was your job to take whatever you were given and
be quiet, and not embarrass the Bulgarians, so the Czechs
set about trying to make something work.  

These drives had the arm visible from above, and by late Sunday
the Czechs had figured out only one thing: they could make the
arm go in and out regularly.

On Monday, the row of drives were lined up and ready, and
when the General came to look, at drives that had never worked
before, he came to attention and saluted the moving arms.

About two months later, they were actually able to use the drives.

Barry



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Phil Smith
Sent: Monday, April 17, 2017 10:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe operating systems?

Barry Merrill wrote:
>At the Czech Tax Bureau in Brno in 1980 I saw what was described as a 
>Ryad clone of an IBM 145 running DOS.

>They had 3420-ish 8 tape drives, and about 100 tapes in their tape 
>library; I think this handled only international transactions.

>Two lab techs in white coats had two of the tape units open with an 
>oscilloscope on a rolling cart, and I was told the problem was that 
>they were forced to get Bulgarian tape drives, and everyone knew you 
>need twice as many drives - one to work and one for spare parts.

Hah! A Russian expat VM guy I knew once told me much the same-read the
following in a heavy Russian accent:
"Vee try to run wee-em, but dese Bulgarian tape drives are s**t."

When he said it, I couldn't help but picture Flintstones-style drives, with
reels that aren't even round...

--
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: Mainframe operating systems?

[Barry Merrill]

At the Czech Tax Bureau in Brno in 1980 I saw what was described
as a Ryad clone of an IBM 145 running DOS.

They had 3420-ish 8 tape drives, and about 100 tapes in their tape library;
I think this handled only international transactions.

Two lab techs in white coats had two of the tape units open with an
oscilloscope on a rolling cart, and I was told the problem was that
they were forced to get Bulgarian tape drives, and everyone knew you
need twice as many drives - one to work and one for spare parts.

Barry


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Timothy Sipples
Sent: Sunday, April 16, 2017 10:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe operating systems?

and MISS (Multipurpose Interactive timeSharing System) and MOS (a UNIX
clone), both available in variants for the ES EVM machines. MOS begat DEMOS,
also available for ES EVM machines. I've neither seen nor touched any of
these Soviet era machines and operating systems. I know very little about
them.

Does anybody know what the Warsaw Pact countries (East Germany, Poland,
Czechoslovakia, etc.) had?



Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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

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

Re: thoughts on z/OS ftp server enhancement.

[Barry Merrill]

The SAS ftp access method is used by many MXG sites who process
their SMF/IMS/zVM/etc data executing MXG on ASCII platforms, 
directly creating the output SAS data library and using disk 
only for those output SAS datasets, which seems to meet the
specifications outlined below.

Except that VSAM is not supported.

Barry


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694





-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Wednesday, March 22, 2017 3:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: thoughts on z/OS ftp server enhancement.

I used to be in the mainframe to ASCII platform file transfer software 
business. There's a name for what you propose -- some 3-letter acronym -- but I 
have forgotten. There is a T in it for Transform. We spent a lot of time 
looking at this, because a recurring customer complaint was "we transferred our 
file and now it's unusable" and it ended up being vendor arguing with customer 
about why you could not translate packed and binary files to ASCII and have 
them be usable.

The problem we wrestled with is there are just so many variables in how record 
layouts work. Non-trivial commercial files inevitably are "well, if there is a 
P in position 51 then it's an accounts payable record and it looks like this, 
but if there is an R then it looks like this, except if there is a C in 
position 92, in which case it's a credit record ..."

You're right, an interesting FTP enhancement might be a generalization of SITE 
FILETYPE=JES|SQL, SITE FILETYPE=somepgm where somepgm would somehow transform a 
file and pass it to FTP. Then the customer could write a COBOL program, say, to 
convert all the packed fields to character on the fly during transmission.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Wednesday, March 22, 2017 1:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: thoughts on z/OS ftp server enhancement.

I am wondering if anyone else thinks the following might be a nice enhancement 
to the z/OS FTP server. At present, when you transfer a file to/from another 
system, you can basically only do a BIN (null) or ASCII transformation. We have 
been doing a lot of ftp's to a Windows server, so we really need an ASCII 
transformation. The problem is that our real data, in a VSAM data set, has 
PACKED DECIMAL and 32 bit internal binary numbers and not just character data. 
So, I was thinking that it might be nice to have a FTP server command which 
would set up a "global" data transformation program as in intermediary. That 
is, the client (on Windows) would do something like:

quote outxform somepgm
get vsam.dataset

And what the FTP server would do is invoke "somepgm" with a parameter of 
"vsam.dataset". The "somepgm" would allocate & open the given data set. It 
would then read the data; transform it; then return the transformed
record(s) to ftp. This would be conceptually similar to what COBOL and SORT do 
when the SORT verb in a program has the USING INPUT PROCEDURE phrase.
Perhaps the parameters to "somepgm" would be a character string and the address 
of a "subroutine" to call to return a record back to the ftp server.

Or maybe something similar to how ftp can do an SQL query, but more generic:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.halu001/db2sqlquerysubmitftps.htm

--
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: track submitted jobs

[Barry Merrill]

Worst case scenario, the TYPE26 JES Purge Record Contains three fields 
that might you can control for accounting purposes  using RACF to control
which USERID can access which Library (but I don't think MEMBER name control
is available).

  SUBMUSER $EBCDIC8. /*SMF26SUI*SUBMITTING*USERID */
  NOTIFYND $EBCDIC8. /*SMF26NN-JOB END EXECUTE*NOTIFY*NODE*/
  NOTIFYUS $EBCDIC8. /*SMF26NU-JOB END EXECUTE*NOTIFY*USERID*/

Barry 

Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of bILHA ELROY
Sent: Thursday, March 23, 2017 6:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: track submitted jobs

For accounting purposes we need to know the name of the library/member that the 
job was submitted from.

Is there any way we can find out. (The job was scheduled not through CONTROL-M 
and similar)

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

FW: When did SMF come along?

[Barry Merrill]

>From MXG Newletter FIFTEEN  Nov 1989 - First Part - 1000 line limit IBM-MAIN 


 CME 20/20:  The History of SMF
  Session M710
August 21, 1989

   H.  W.  Barry Merrill, PhD
  Merrill Consultants
 Dallas, Texas
 SHARE Installation CM4


ABSTRACT

SMF  became available 20 years ago with OS/360 Release 18.  SHARE's 1964
SORC report was part of the input to  IBM's  1966  SMF  design  document
(authored  by  an  IBMer who had been a SHARE board member).  The design
objective was two-fold:  the stated SHARE requirements for  control  and
evaluation  of  the  installation,  and  the  unstated  need  for IBM to
understand how its OS and its program products were  being  used  (which
and  how  much).   That  1966  design  document,  when compared with the
current SMF implementation, will be shown to be remarkably  accurate  to
the  needs  of users even today!  The presentation will also discuss the
never-announced  and  never-released  IEHMAN   report   package!This
presentation is based on recently de-classified IBM design documents and
interviews with  the  original  designers  and  developers  of  the  SMF
product.


CONTENTS

 A. Jun 15, 1964 SORC Report 46-47
 B. 1964-1967 Brockish Interview Notes   48-49
 C. Aug 25, 1967 Task Force Report  50
 D. Nov  1, 1967 IBM Memo   51
 E. Nov  1, 1966 Objectives  52-57
 F. Mar 13, 1967 Addendum I Subset 2 58-59
 G. Mar 14, 1967 Addendum II60
 H. Jul 27, 1967 Proposal Memo  60
 I. 1967-1969 Schiffman Interview Notes  61-62
 J. Oct 16, 1968 Subset I Final 62
 K. Jan 31, 1969 Subset II Final 63-66
 L. Jun 25, 1969 Subset II Final Final  67
 M. IEHMAN  68
 N. Jul, 1969 Release 1869
 O. Oct, 1969 Release 18.6  70
 P. Jun, 1970 Release 1971
 Q. Feb, 1971 Release 2072
 R. Aug, 1972 Release 21.6  72
 S. 1972-1974 Merrill Notes  73-74
 T. 1975-1977 Hankison Interview74
 U. Aug  1, 1977 Objectives 75
 V. Author's summary76
 W. Contributors to this paper  76



Copyright  (C) 1989 Merrill Consultants, Dallas, Texas.  This paper will
be published in a 1989 issue of the "Technical Newsletter for  Users  of
MXG".   Permission  is  hereby  granted  to SHARE, Inc.  to publish this
presentation in SHARE  Proceedings.   Merrill  Consultants  retains  its
right to distribute copies of this presentation to whomever it chooses.

On April 7, 1964, IBM Announced OS/360. Were you computer literate then?

The  IBM  Design  of SMF Was The Direct Result Of The 1964 SHARE Systems
Objectives and Requirements  Committee  "SORC".   The  SORC  Report  was
produced only two months after OS/360 announcement!


   APPENDIX F
Report of SHARE Systems
 Objectives and Requirements Committee
 June 15, 1964

G.E. Bryan, Chairman  L.   Cohn
P.A. Cramer   R.   Gillespie
G.H. MealyC.H. Weisert

"IV.  JOB ACCOUNTING AND SYSTEM PERFORMANCE MEASUREMENT

Theadventof   multi-programmed   and   multi-processor   machine
configurations  has  re-emphasized  the  always  present  need  for  job
accounting  and  made  even  more  important  the much neglected area of
machine and program  performance  measurement.   Operating  systems  for
System/360  must  provide  as a standard feature a job accounting system
which retains records  useful  for  both  ordinary  cost  allocation  of
machine   component  time  and  measurement  of  hardware  and  software
performance.

Accounting and statistical information should be carried in the  system
on  a  job basis and identified by the following information supplied by
the submitter of the job:

1. A job number.
2. A programmer identification number.
3. An identification specific to the run.
4. Priority.
5. Other information as deemed necessary by
   the individual installation.

In addition, in order to facilitate automatic  scheduling  of  jobs  for
optimum  performance, the following should be supplied either by the job
submitter or, for "normal cases," be defined  by  installation  standard
parameters.

6. E

FW: When did SMF come along?

[Barry Merrill]

>From MXG Newletter FIFTEEN  Nov 1989 - First Part - 1000 line limit IBM-MAIN 


CME 20/20:  The History of SMF
  Session M710
August 21, 1989

   H.  W.  Barry Merrill, PhD
  Merrill Consultants
 Dallas, Texas
 SHARE Installation CM4


ABSTRACT

SMF  became available 20 years ago with OS/360 Release 18.  SHARE's 1964
SORC report was part of the input to  IBM's  1966  SMF  design  document
(authored  by  an  IBMer who had been a SHARE board member).  The design
objective was two-fold:  the stated SHARE requirements for  control  and
evaluation  of  the  installation,  and  the  unstated  need  for IBM to
understand how its OS and its program products were  being  used  (which
and  how  much).   That  1966  design  document,  when compared with the
current SMF implementation, will be shown to be remarkably  accurate  to
the  needs  of users even today!  The presentation will also discuss the
never-announced  and  never-released  IEHMAN   report   package!This
presentation is based on recently de-classified IBM design documents and
interviews with  the  original  designers  and  developers  of  the  SMF
product.


CONTENTS

 A. Jun 15, 1964 SORC Report 46-47
 B. 1964-1967 Brockish Interview Notes   48-49
 C. Aug 25, 1967 Task Force Report  50
 D. Nov  1, 1967 IBM Memo   51
 E. Nov  1, 1966 Objectives  52-57
 F. Mar 13, 1967 Addendum I Subset 2 58-59
 G. Mar 14, 1967 Addendum II60
 H. Jul 27, 1967 Proposal Memo  60
 I. 1967-1969 Schiffman Interview Notes  61-62
 J. Oct 16, 1968 Subset I Final 62
 K. Jan 31, 1969 Subset II Final 63-66
 L. Jun 25, 1969 Subset II Final Final  67
 M. IEHMAN  68
 N. Jul, 1969 Release 1869
 O. Oct, 1969 Release 18.6  70
 P. Jun, 1970 Release 1971
 Q. Feb, 1971 Release 2072
 R. Aug, 1972 Release 21.6  72
 S. 1972-1974 Merrill Notes  73-74
 T. 1975-1977 Hankison Interview74
 U. Aug  1, 1977 Objectives 75
 V. Author's summary76
 W. Contributors to this paper  76



Copyright  (C) 1989 Merrill Consultants, Dallas, Texas.  This paper will
be published in a 1989 issue of the "Technical Newsletter for  Users  of
MXG".   Permission  is  hereby  granted  to SHARE, Inc.  to publish this
presentation in SHARE  Proceedings.   Merrill  Consultants  retains  its
right to distribute copies of this presentation to whomever it chooses.

On April 7, 1964, IBM Announced OS/360. Were you computer literate then?

The  IBM  Design  of SMF Was The Direct Result Of The 1964 SHARE Systems
Objectives and Requirements  Committee  "SORC".   The  SORC  Report  was
produced only two months after OS/360 announcement!


   APPENDIX F
Report of SHARE Systems
 Objectives and Requirements Committee
 June 15, 1964

G.E. Bryan, Chairman  L.   Cohn
P.A. Cramer   R.   Gillespie
G.H. MealyC.H. Weisert

"IV.  JOB ACCOUNTING AND SYSTEM PERFORMANCE MEASUREMENT

Theadventof   multi-programmed   and   multi-processor   machine
configurations  has  re-emphasized  the  always  present  need  for  job
accounting  and  made  even  more  important  the much neglected area of
machine and program  performance  measurement.   Operating  systems  for
System/360  must  provide  as a standard feature a job accounting system
which retains records  useful  for  both  ordinary  cost  allocation  of
machine   component  time  and  measurement  of  hardware  and  software
performance.

Accounting and statistical information should be carried in the  system
on  a  job basis and identified by the following information supplied by
the submitter of the job:

1. A job number.
2. A programmer identification number.
3. An identification specific to the run.
4. Priority.
5. Other information as deemed necessary by
   the individual installation.

In addition, in order to facilitate automatic  scheduling  of  jobs  for
optimum  performance, the following should be supplied either by the job
submitter or, for "normal cases," be defined  by  installation  standard
parameters.

6. E

Re: When did SMF come along?

[Barry Merrill]

 1966-1969  IBM  design  and  implementation process was better
structured, managed, and documented  than  your  company's  most  recent
managed software project in 1989.

7.   Based  on this example of IBM design practices of twenty years ago,
imagine the detail we would find in today's IBM design documents!

8.  SMF made IBM pre-eminent in the business of real data processing  by
giving  DP  management  actual  measures  of  the resource usage and the
service (response) for each user.  DP could then "manage by  objectives"
and  prove  to  the  president  the  value  and costs of the services DP
provided the company.  No other vendor  of  hardware  and  software  has
provided the accurate measurements that IBM has given its customers.

9. As good as it is, it still isn't perfect:

   MVS/ESA added three important CPU measures to
   the type 30 (task level) record,
   RCT  - Region Control Task CPU
   SLIH - Second Level Interrupt Handler CPU
   HPT  - Hiperspace CPU
   but we do not have these same CPU measures
   in the type 72 (performance group) record.

   SHARE REQUIREMENT, ANY ONE?



Contributors:

With  sincere thanks for the dedicated developers designers and users of
SMF data, I especially salute these contributors to this research:

 Bob Brockish, (retired) IBM Tom Bell, Rivendel Consultants
 Lynn Weissenreider, IBM Boulder Brian Currah, BDC Computer Services
 Saul Schiffman, IBM Japan   Aron Eisenpress, CUNY
 Ron Hankison, IBM Kingston  Mario Morino, Morino Associates
 Dick Armstrong, IBM Gaithersburg
 Jim Doyle, IBM Poughkeepsie
 Jack Higgins, IBM Publications

especially  for   their   treasure-trove   of   original   IBM   project
documentation   as  well  as  their  time  in  reminiscing  on  personal
remembrances.




Barry Merrill


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694

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

Re: Check out Massive Amazon cloud service outage disrupts sites

[Barry Merrill]

John Deere's data center in the 70s had multiple AC providers but still had 
Midwest lightning
induced outages, but the data center manager was unsuccessful in installing a 
diesel backup
system because the only UPS system that met their power needs was available 
ONLY with a 
Caterpillar Diesel engine, and the board would not approve.

After the third or fourth outage, the data center manager was finally allowed 
to build 
a GREEN windowless building to house the diesel and generator, and they snuck 
the yellow 
Cat engine into its home in the middle of the night.

Barry Merrill


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Wednesday, March 1, 2017 11:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Check out Massive Amazon cloud service outage disrupts sites

I heard about a major electric utility that had an influential VP who believed 
that it was 'unseemly' for the company to spend money on backup power. Sort 
dissing their own product. He blocked all efforts to install diesel generators. 
Thankfully he is long gone. A major multi-state event in the mid-2000s induced 
the company to finally invest in serious power backup and DR. 

I love the old saw about the cobbler's children going without shoes.  

.
.
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 Charles Mills
Sent: Wednesday, March 01, 2017 9:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Check out Massive Amazon cloud service outage disrupts 
sites

And you're in the electric power BUSINESS!

Up here in northern CA we used to joke that PG's company song should be the 
Simon & Garfunkel "Hello Darkness my Old Friend."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Wednesday, March 1, 2017 8:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Check out Massive Amazon cloud service outage disrupts sites

Our data center folks insist on dual power feeds for everything, sometimes 
infuriatingly so. To test power redundancy, they occasionally drop one power 
feed or the other--with ample heads up--and check that all devices are 
functioning. Other than call-home events, we have not had any surprises so far. 

Testing for a full power outage (both sides) is a lot harder, but it has been 
done here a few times.  


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

[Barry Merrill]

I recall a meeting with the President of Sun Information Services
with both the Marketing folks and all of the SYSPROGs, and one
SYSPROG raised the question of why the marketing folks got these
big bonuses but the SYSPROGs did all the work with no real bonus..

The president replied, "We'll, you techies first need to walk
in the shoes of the marketing folks to understand what they
have to do to make a sale".

Turning to one of the marketers beside him who was all spiffed
up with Italian patent leather shoes, the SYSPROG replied
 
"Walk in your shoes, hell I can't even AFFORD them."

Barry



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Mattson
Sent: Wednesday, February 15, 2017 9:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Loyalty

Jack Woehr makes some good points.
Most sysprogs are not very good at public relations.  We do not make much 
noise, blow our own horns and are like proof readers for a publisher... IF we 
do our jobs perfectly no one notices, which is right, BUT if we make a mistake 
EVERYONE notices.  I have been fortunate to have/choose some very good bosses 
(interviews are for me to evaluate the boss of course) who understood and 
appreciated what sysprogs do.
We used to laugh at annual meetings where the marketing departments handed 
out paper awards and plaques left and right, and showered themselves with 
praise.  We sat in the back thinking that we earned more than any two of them, 
and remembered that they could not do a thing without us.  Lack of loyalty to a 
job does not mean we have no Pride in our work.

--
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: SYSLOG/OPERLOG Keyword Search

[Barry Merrill]

JCL===//  EXEC SAS
JCL===//SYSLOG DD DSN=YOUR.SYSLOG,DISP=SHR
JCL===//SYSIN DD *   
DATA _NULL_;
INFILE SYSLOG;
INPUT @;
IF INDEX(_INFILE_,'TEXT I WANT') GT 0 THEN LIST;

Nope, it ain't SPLUNK but will search any file and print the record.

Barry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Friday, February 10, 2017 2:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYSLOG/OPERLOG Keyword Search

The hardest task in searching the system log is that rarely are you interested 
only in a particular character string. What you normally want is the contextual 
environment of that string. Even a message id is not very useful if all you get 
is the one line containing that id. You really need the full, often multiline 
message that starts with message id but generally contains vital information in 
subsequent lines. 

I don't know of any tool that can do the needful except a special purpose 
program written for the purpose. We have one here written eons ago in PLI that 
serves a common purpose. Not sure that we're ready to share it, but I’m dubious 
of finding a GA tool that satisfy this common requirement. As others have said, 
if the log in question is on DASD, you can use ISPF browse to find a target 
string and then look at the surrounding text. May be easy; may be really time 
consuming. 

.
.
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 Pew, Curtis G
Sent: Friday, February 10, 2017 6:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: SYSLOG/OPERLOG Keyword Search

On Feb 10, 2017, at 8:30 AM, Donald J.  wrote:
> 
> What programs (free or IBM or other) are available for doing 
> historical keyword searches against the SYSLOG or OPERLOG archives?  ISPF or 
> otherwise.

I don’t think this is exactly what you’re asking for, but we forward our 
OPERLOG to Splunk and then we can do all kinds of searches and reports.

--
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


--
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: Paper tape (was Re: Hidden Figures)

[Barry Merrill]

The submarine navy went a step further with the five hole TTY tape in a
system
called HARE - High (speed?) Radio (emission?) for both speed and security in
1964.

Connected to the Collins URC transmitter, each hole in a character caused a
transmission on a different HF frequency, and so there were a dozen receiver
sites
all around the world listening simultaneously for a signal on all five
frequencies
(that changed hourly) at 250 words per minute, and the messages were encoded
and
typically only 30-40 characters long, so the HARE transmission from the
submarine
was undetectable.  We tested south of Greenland and were copied by seven
receiver
sites on four continents. 

(And, yes, the HF antenna must be above the water to
transmit HF radio signals - a 30 foot vertical on the top of the snorkel
mast
works great.)

Barry Merrill

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Grinsell, Don
Sent: Friday, January 13, 2017 4:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Paper tape (was Re: Hidden Figures)

I remember using paper tape in high school in the mid-70's.  Punch cards in
college and my first job.  I joined the army in 1981.  I was eventually
assigned to a signal unit in 1984 and lo and behold I had paper tape again
in our radio teletype vans.  We transcribed the messages onto the tape and
then powered up the hf radio for a relatively shorter transmission window.
This was during the cold war and the theory was that if you were on air for
much longer than 30 seconds at a time our friends on the other side of the
iron curtain could triangulate your position and pretty much ruin your day.

"The power of accurate observation is often mistaken for cynicism by those
who have not got it."  -- George Bernard Shaw


--
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: Paper tape (was Re: Hidden Figures)

[Barry Merrill]

The only input to the IBM 610 at the University of Notre Dame
in October, 1959, was the standard 5-hole teletype paper tape.


  Sophomore Year, Fall, 1959.

  Fiftieth Anniversary of Digital Computing at the University of Notre
  Dame, 2009:

  In September, 1959, I was a sophomore at Notre Dame, taking EE 101,
  the basic Electrical Engineering Circuits course with class three days
  a week, and an associated Laboratory on Tuesdays.  The first week's
  Lab project had us measuring voltages and currents with many very old
  and some new meters, each with a different ohms-per-volt
  characteristic, comparing their accuracy, and we learned how to
  prepare a formal report of an experiment.  The second week's lab
  experiment was to calculate the value of the Determinant of a
  four-by-four matrix, primarily to show us the difference between
  engineering and math.  The corresponding math class we were all taking
  would have the professor show us by Cramer's Rule how to calculate the
  value of a linear system by dividing the determinant of matrix A by
  the determinant of B to get the blackboard answer
 X = [A] / [B]  = 7
  but this second week's lab project was to demonstrate that the actual
  work of an engineer would be to calculate each of those determinants,
  which involved a great deal of arithmetic and was not quite as simple
  as the Math Prof's immediate answer.

  As the EE Lab Professor (name now forgotten, but rather aged as I
  recall) finished the instructions for that lab project, he said "I
  have been instructed to read this note to all EE students", and
  picking up a one-page, dittoed notice, he continued "The IBM
  Corporation has donated a Model 610 digg-it-tal, er, digital,
  computer, located in room 240, and students can sign up for blocks of
  time to use it."  Slamming the sheet of paper face down, he then said
  "those digital things will never amount to anything, but next year, as
  Juniors, you will be able to go across the hall to room 241 and use
  the Bendix G15 Analog Computer - that's how we Electrical Engineer's
  solve real problems!"
  In 2013, John Ehrman took Judy and I thru the Computer Museum in
  California, where I related this story and saw their Bendix G15
  computer, but it is described as a digital computer, but I was still
  certain of my story.  Then, in 2014, I posted this first experience
  to the IBM-Main forum, and one respondant said the G-15 was digital.
  Fortunately, my story was proven when a poster noted that if the
  B-15 had the optional  DA-1, Differential Analyzer hardware, it 
  provided all of the analog hardware, the potentiometers and meters,
  and plugboard circuitry that made it function as an analog computer, 
  even though all of the underpinnings that processed the data were 
  digital circuits and the old prof would have seen it only as an 
  analog computer.
P.S. In those early years, there WERE problems far more suited to
 analog computation, especially analysis of transients, before
 the speed of digital computers, and tools like the Fast Fourier
 Transform, were able to sample sufficiently fast to eliminate
 the analog advantage.

  So I decided to investigate this IBM Digital Computer, and went to
  room 240, which was on the left at the end of the hall that opened to
  the very large lab with scores of motors and motor-generator that had
  its large doors open to the warm September afternoon.  I looked thru
  the small window in the door and saw a 3 foot high, 5 foot wide gray
  machine to the left of a table with a Selectric typewriter, and saw
  someone who I assumed to be a junior/senior, leaning over the
  typewriter.  I opened the door to enter.  As the door unhinged, so did
  the student, shouting "Shut that G.D. door!" as he strode across the
  room to the door, flailing his arms.  As he stepped out into the hall
  screaming "Didn't you read the damn sign?” he then saw that his
  hand-written sign to "Get The Operators Permission Before Entering"
  had fallen, face down on the floor.  Calming, he informed me that you
  must get the operator's attention, because the computer room was air
  conditioned for the vacuum tubes and he needed to put the machine in
  "QUIESCE/STOP" mode (which took 5-10 seconds), as only then was it
  safe shuffle in, slowly, so as to not bring in warm air.  The vacuum
  tubes were so temperature sensitive, that air currents would cause
  computation to fail, requiring a program restart.

  He pointed me to the IBM manuals on the table beside the Selectric,
  and I began to read, at page one.  Several hours later, I had learned
  how to punch the paper tape input (like the paper tape used in
  Radioteletype at my ham radio station), and could print the tape on
  the Selectric, and had used the IBM example to add 2 + 2 and print 4,
  and I decided I would program the calculation of the 

Re: 32767?

[Barry Merrill]

It is NOT true that RECFM=V on z/OS has ONLY an RDW.

RECFM=V on z/OS has BOTH the BDW and the RDW.

RECFM=V on DOS has only a 4-byte RDW.


NOTE: THE INFILE VFILE IS is RECFM=V,LRECL=32756,BLKSIZE=32760

When read with RECFM=U you can see both the BDW and the RDW.


  
 RULE:
+1+2+3+4+5+6+7+-
---8+9+0  
  
 1   CHAR  THIS IS THE TEST STRING IN RECFM V 42
 ZONE  02000200ECCE4CE4ECC4ECEE4EEDCDC4CD4DCCCD4E
 NUMR  0A0006003892092038503523023995709509536405

Barry Merrill


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Hunkeler
Sent: Friday, December 16, 2016 9:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: Re: 32767?

>The BLKSIZE must be 4 more than LRECL for a RECFM=V dataset and 8 for a
RECFM=VB dataset. 


When it comes to BLKSIZE versus LRECL, there is *no* difference between
RECFM=V and RECFM=VB. And even the print control character variants with the
additional A or M in th RECFM do not make it any different. A block is a
block and a such it has a 4 byte BDW (for RECFM=V only, of course). 


To "B" or not only tells the reader or writer code whether exactly one or
possibly multiple logical records are in the block. It doesn't change the
format of the block.


--
Peter Hunkeler



--
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: zOSMF and CMF?

[Barry Merrill]

The only difference in the CMF and RMF SMF records is the value in the
PRODUCT name in CMF is either CMF-CPM or CMF-IPF.

But I don't know if those records are accepted by zOSMF.

Barry


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Dyck, Lionel B. (TRA)
Sent: Tuesday, December 6, 2016 10:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zOSMF and CMF?

Does anyone know if CMF can interface with the zOSMF Performance modules in
place of RMF?

I've not found anything in the CMF pubs (so far)

--
Lionel B. Dyck
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10) Information and
Technology, IT Operations and Services


--
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: Address space

[Barry Merrill]

I think maybe this discussion is for the Early Address Spaces, that
among other things, create SMF 30 subtype 6 interval records instead
of subtype 3s.  My notes list these  as known Early Address Spaces
that create subtype 6's:


 APPC ASCH AUTAM92A AUTAM92B AUTO92S  BLSJPRMI CAS9   CSAA
 HSAPIPLC HZR  IFGEDI   INIT JES2 LLA  MIAMIMASC
 MIMEDI   RESOLVER RRS  SOFTAUDT TFS  TSS  VLF

Barry


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Hunkeler
Sent: Tuesday, November 15, 2016 2:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: Re: Address space

>For RACF, several STCs like 'MASTER SCHEDULER JCL' and subsystem services
are started BEFORE RACF is started, but the SAF interface is already in
place at that stage of IPL. 
 

So, I'm not sure what you mean by "BEFORE RACF is started"?  Are you talking
about the RACF subsystem address space called RACF? If so, this is *not* a
required function.
--
Peter Hunkeler 

--
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: SAS Error

[Barry Merrill]

There are SAS options that control whether SAS will read all of the 80 bytes or 
only the first 72.

And SAS reads columns 73-80 of the first //SYSIN statement and if there are no 
line numbers, 
assumes the rest of the input is also unnumbered, so a later line with a line 
number can trip
up that presumption.

Barry Merrill


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ron Thomas
Sent: Wednesday, November 2, 2016 11:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SAS Error

Thanks Donald ! I looked at the code and there was line numbers in 73-80 col 
and in removed those and it worked fine . Thanks !

--
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: SAS Error

[Barry Merrill]

The 180 error means SAS could not resolve the syntax,
and there is nothing VISIBLY wrong in your program.

Post the full SAS log of the job and/or look for an unprintable
character in your SAS program.

Barry


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ron Thomas
Sent: Wednesday, November 2, 2016 10:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SAS Error

Hi .

I am completely  new to SAS  and when i executed the below  one to write 111 
char to a dataset , the following below error message is showing up could 
someone please let me know where the issue is ?


//RDDATA   EXEC  SAS,WORK='4,4'
//*
//SASLIST  DD  DSN=RS32UVT.SAS.SASLIST,
// DISP=SHR
//TESTF1   DD  DSN=RS32UVT.TEST.FILE,
// DISP=SHR
//SYSIN  DD *
OPTIONS NOCENTER;
DATA _NULL_ ;
  FILE TESTF1 ;
   PUT @1 '111 '
   ;
RUN;
//SYSPRINT DD SYSOUT=*


ERROR 180-322: Statement is not valid or it is used out of proper order.
ERROR 180-322: Statement is not valid or it is used out of proper order.
ERROR 180-322: Statement is not valid or it is used out of proper order.

Thanks
Ron T

--
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: CEEDUMP possible following 'new' failure

[Barry Merrill]

I have this note from  a few years ago that consurs:
 
- Early SAS notes recommended REGION=0M, but with early V9.1, only
  for diagnostics AFTER an out of memory condition, a specific REGION
  was recommended in http://support.sas.com/kb/18401:
"The thought is that if we have exhausted the full region and
 abnormal termination occurs as a result there is not sufficient
 ceiling within the address space to properly clean up. This can
 lead to damaged libraries, potential hanging and looping within
 the address space.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Hunkeler
Sent: Sunday, October 9, 2016 9:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: Re: CEEDUMP possible following 'new' failure

>Fault Analyzer showed that the last thing that happened in the address
space was trying to load some z/OS routines for termination (if it was not
memory termination then it must have been task termination) and failed to
load those routines because of an out of storage condition. 




I have in mind that, at least in earlier times, it was recommended *not* to
code REGION=0M? With REGION=0M the code can to eat up all storage in the
address space. Of course, authorized software may easily  overcome any
REGION setting (I guess).


--
Peter Hunkeler



--
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: Software is unpatentable?

[Barry Merrill]

About a decade ago, a person from the US Patent and Trademark Office called me 
to ask if
I could provide a machine readable copy of my 1984 "Merrill's Guide to Computer 
Performance
Evaluation Using the SAS System".  The caller said they had found it their most 
used source 
with which to deny software patent applications that were already state of the 
art in 1984.

Barry


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694





-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Westerman
Sent: Saturday, October 8, 2016 4:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Software is unpatentable?

I disagree.  Not only because I own several software patents, but because 
Patents are not meant to merely cover the invention of physical objects as you 
stated.  Under U.S. patent law, any person who "invents or discovers any new 
and useful process, machine, manufacture, or composition of matter, or any new 
and useful improvement thereof, may obtain a patent." ... The only reservation 
is that the invention must not be obvious.

I agree that some patents are granted for software that should never be 
patented because it fails the obviousness test.  That's simply a problem with 
the patent examiner's inexperience with software and coding techniques.  That 
doesn't mean that all software is non patent-able just because a few patent 
applicants abuse the process.  There is absolutely no textual support for the 
creation of any judicial exceptions to patent eligibility.  There are three 
identified judicial exceptions which are: laws of nature, physical phenomena 
and abstract ideas. If the claim does NOT seek to protect one of those judicial 
exception then the claim is patent eligible. In the case you were referring to, 
the problem with the claims in that trial were that they tended to be very 
abstract and vague and did nothing to further the limits of the patent.  Had 
they specified specifics, the patent probably would never have been granted in 
the first place.  Just because the patent application was vague and 
inconsistent, doesn't make all software patents bad, nor does it reflect badly 
on any other specific software patents. 

For instance, I had an idea several years ago to try to figure out a way to 
send an email (or any number of emails) at the end of every job without any 
system mods or exits (which would make the software too dependent on the 
Operating system code level).  At that original stage of my thinking, as an 
abstract idea, it was not patent-able, but that in itself would not stop a lot 
of companies from patenting it and that is unfortunate.   

It took a while but I eventually figured out a way to create and send the email 
(or even SMS text message) that contains all of the relevant information from 
the job, it's condition codes and the JES and task's SYSOUT if you wish, plus 
any static or user generated text (including hundreds of variable data 
elements) all without any JCL changes, system exit code, mods etc.  It was 
extremely difficult to just figure out a way to do it and then I spent 
literally years working on different ideas (most of which were discarded), and 
finally came up with a repeatable and innovative way to do it.  In fact, after 
I figured it out, I thought of 4 completely separate ways to implement the 
basic code to accomplish the same thing.  No one else thought of how to do it, 
or still does know how to do it.  But... one of the sites that I allowed to 
beta test the working code, (another software company which I had performed 
development work for in the past who I shall not mention), decided to not only 
copy the idea, code and all, but to market it and actually got it into 10 beta 
test sites.  My patent was still pending, but without that protection, the 
other company (which is considerably larger) would have just laughed in my 
face.  In this case, they not only stole the code (which violated my 
copyright), but they even attempted to patent the process.  I found out about 
it directly from the patent office of all places.:)  They contacted me because 
the company actually included one of my drawings in their filing with my patent 
application number at the bottom.  Needless to say, they backed off and agreed 
to not only stop marketing it,and destroy the software copies, but they agreed 
to cease all "development of any similar products" for a period not less than 
10 years.  Plus, all of their developers had to agree to be bound by the terms 
of the agreement.

In the article, the judge was completely missing the patent boat.  Had I not 
already applied for my patent, they would have kept right on wit

Re: remote system support (i.e. the data center is 2 states away from you).

[Barry Merrill]

"amazing how many of us are also musicians"

In 1971-2, State Farm hired 1500 would-be coders and send them thru 9 weeks
to learn to code in PL/1, and they had a job at the end if they had learned
to code. The three largest groups of successful coders, in about equal count,
were those that played a musical instrument, or knew more than one language, 
or had a math/engineering degree.

Barry Merrill

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Thursday, September 29, 2016 11:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: remote system support (i.e. the data center is 2 states away from 
you).

This is a great post! Quite some years ago a local YMCA activities director 
acquired a pager. People thought she was burdening herself with an electronic 
tether. Quite the opposite, she argued. She trusted her staff for most 
problems, but if she was needed, she could respond immediately--from the pay 
phone nearest the beach where she was lounging. ;-)

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Mattson
Sent: Thursday, September 29, 2016 9:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: remote system support (i.e. the data center is 2 states 
away from you).

Fascinating subject for most of us, just look at all the replies.
Makes me sorry that I am close to retirement when things keep getting more 
interesting.
Many years ago that I started doing all of the zOS maintenance because the 
rest of the group was eliminated or switched to Unix/Win.  Incredible tools 
developed allowed that to happen.  I could download and install major systems 
in no time at all.  We went from a bunch of zOS people doing systems to one zOS 
and a much larger bunch doing Unix/Win. They called this "progress".  Hmmm.
 How remote support happened at Acme Anvils. I installed TCPIP on the MF 
when no one in management had any interest in it. I bought and paid for a very 
expensive cell phone and software many years ago which allowed me to login to 
work so that I could play Renaissance music at faires all week-end while 
on-call. (amazing how many of us are also musicians)  Once others saw this, 
everyone had to have it.  It was worth every cent.
After all these years the major obstacle to remote support is that 
management still had not learned how to manage it--- In my (not so) humble 
opinion.
My comment to John McKown is "what happens when you want to go on a real 
vacation", you know, Europe or Asia?  I realize that one reason I am at my 
current consultant job is so that the FTE can go on vacation.
Humbling, but at this point, no problem. I make myself useful.


--
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: Translating a DEVTYPE from LISTC into something usable?

[Barry Merrill]

This table from MXG should cover most device mappings:


 /* COPYRIGHT (C) 1985,2015 BY MERRILL CONSULTANTS DALLAS TEXAS */
 /* LAST UPDATED: OCT 15, 2015.  CHANGE 33.249.   */
 /*/
 /***  VMACUCB INCLUDED CODE  /
 /*/
 /* VMACUCB DECODES THE DEVCLASS AND DEVTYPE FIELDS FROM AN   */
 /*   MVS UCB (UNIT CONTROL BLOCK) INTO THE VARIABLE  */
 /*   DEVICE. IT ALSO CREATES THE VARIABLE LCU IF IT DOES NOT */
 /*   ALREADY EXIST (NOT ALL MVSXA RECORDS CONTAIN LCU YET, BUT   */
 /*   I BELIEVE ULTIMATELY THEY WILL SO - CREATING LCU HERE ELIMINATES*/
 /*   A VARIABLE NOT FOUND CONDITION. */
 //
 /***   THIS MODULE IS INCLUDED BY THE FOLLOWING MXG MODULES:  ***/
 /***  ***/
 /*** VMAC10   VMAC1415  VMAC19VMAC62VMAC64***/
 /*** VMAC74   VMAC75VMAC8911  VMACEXC1  VMACTMNT  ***/
 /*** AND INDIRECTLY BY VMAC4,VMAC5,VMAC30,ANY WITH DEVICE SEG.***/
 //
 /*===END OF COMMENTS===*/

   IF LCU=. THEN LCU=.;  /* CREATES VARIABLE IF NEEDED */
   IF DEVNR=. THEN DEVNR=.;
   IF MVSXA=. THEN MVSXA=.;
   /* BACK WHEN THEY EXISTED, THIS CODE WAS USED FOR MSS
   IF DEVNR   ='1...'B THEN DEVICE='MSS'; */
   IF DEVCLASS=00X AND
( (DEVNR=0FFFX AND NOT MVSXA AND NOT FACOMMSP) OR
  (DEVNR=7FFFX AND (MVSXA OR FACOMMSP))  )
THEN DEVICE='VIO';
   ELSE IF DEVCLASS=20X THEN DO;
 IF  DEVTYPE=04XTHEN DEVICE='9340   ';
 ELSE IF DEVTYPE=06XTHEN DEVICE='2305-1 ';
 ELSE IF DEVTYPE=07XTHEN DEVICE='2305-2 ';
 ELSE IF DEVTYPE=08XTHEN DEVICE='2314   ';
 ELSE IF DEVTYPE=09XTHEN DEVICE='3330   ';
 ELSE IF DEVTYPE=0DXTHEN DEVICE='3330-11';
 ELSE IF DEVTYPE=0AXTHEN DEVICE='3340   ';
 ELSE IF DEVTYPE=0BXTHEN DEVICE='3350   ';
 ELSE IF DEVTYPE=0CXTHEN DEVICE='3375   ';
 ELSE IF DEVTYPE=85XTHEN DEVICE='6421   ';/*FACOM*/
 ELSE IF DEVTYPE=0EXTHEN DEVICE='3380   ';
 ELSE IF DEVTYPE=0FXTHEN DEVICE='3390   ';
 ELSEDEVICE='DASD   ';
   END;
   ELSE IF DEVCLASS=80X THEN DO;
 IF  DEVTYPE=80XTHEN DEVICE='3480   ';
 ELSE IF DEVTYPE=01XTHEN DEVICE='2400   ';
 ELSE IF DEVTYPE=03XTHEN DEVICE='3420   ';
 ELSE IF DEVTYPE=81XTHEN DEVICE='3490E  ';
 ELSE IF DEVTYPE=83XTHEN DEVICE='3590   ';
   END;
   ELSE IF DEVCLASS=08X THEN DEVICE='UNITREC';
   ELSE IF DEVCLASS=10X THEN DEVICE='GRAFICS';
   ELSE IF DEVCLASS=40X THEN DEVICE='COMM   ';
   ELSE IF DEVCLASS=41X THEN DO;
 IF  DEVTYPE=05X  THEN DEVICE='CTC-OSA ';
 /*OSA*/
 ELSE IF DEVTYPE=06X  THEN DEVICE='CTC-OSAD';
   /*OSA DIAG DEV */
 ELSE IF DEVTYPE=06X  THEN DEVICE='CTC-OSAD';
   /*OSA DIAG DEV */
 ELSE IF DEVTYPE=07X  THEN DEVICE='CTC-IQD ';
/*HIPERSOCKETS*/
 ELSE IF DEVTYPE=09X  THEN DEVICE='CTC-OSAN';
  /*OSA ZBX NETWK */
 ELSE IF DEVTYPE=0AX  THEN DEVICE='CTC-OSAM';
  /*OSA ZBX MGMT NETWK*/
 ELSE IF DEVTYPE=32X  THEN DEVICE='CTC-FIC ';
   /*FICON*/
 ELSE  DEVICE='CTC ';
   END;
   ELSE IF DEVCLASS=04X THEN DEVICE='CHARRDR';
   ELSE IF DEVCLASS=00X THEN DEVICE='00X';
   ELSE  DEVICE='OTHER  ';
  /* INCLUDE MEMBER IMACUCB IN CASE YOU WANT TO DEFINE OTHER */
  /* VALUES OF DEVICE (EG. DEVICE='SILO' OR DEVICE='AUTOLOD', */
  /*  PERHAPS BASED ON SPECIFIC DEVNR'S (OR RANGES OF UCBS).  */
   %INCLUDE SOURCLIB(IMACUCB);
  /* END OF MEMBER VMACUCB*/


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of John Eells
Sent: Thursday, September 22, 2016 1:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Translating a DEVTYPE from LISTC into something usable?

Some other trivia about DEVTYPE in catalog entries...

The first two bytes are "feature" bits.  For modern disk, it will always be
x'3010'.  These bits 

Re: k4t4949b (September 2016 refresh of the z/OS 2.2 manuals)

[Barry Merrill]

We use 7-zip to generate our MXG distribution file for ASCII platforms,
a zipped source director, and found that by naming the output file
extension of .zip  instead of .7z, we've never had a reported problem.


Barry


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694





-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Graeme Gibson
Sent: Sunday, September 18, 2016 12:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: k4t4949b (September 2016 refresh of the z/OS 2.2 manuals)

It's possible that someone at IBM has assumed that 7-Zip produces .zip files, 
which it does not.

7-Zip normally uses the file extension, or type, of ".7z", not '.zip".

It's unfortunate, but possibly not inadvertant, that the developers of "7-Zip" 
chose a product name that suggests they *are* related.
Because of the confusion, products that do support the industry-standard .zip 
file architecture have been pressured by their clients to implement support for 
.7z files.  It's clever. I'm reminded of the cuckoo.

Cheers all,
Graeme

http://www.slikzip.com


On 2016/09/18 7:51 AM, John Laubenheimer wrote:
> To me, this is somewhat bad technique on IBM's part. This doesn't seem to 
> have been documented anywhere, and requiring a 3rd party utility to read the 
> file is not really a good idea. But, 7-Zip works (and is free)!
On 2016/09/18 12:41 PM, John Laubenheimer wrote:
> I guess I should have said that I think that this is a mistake on IBM's part, 
> and not an intentional change.
>

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

Don Deese

[Barry Merrill]

DONALD RAE DEESE, 74, passed away on Tuesday, August 23, 2016 at his home in

Hartfield, VA.  One of thirteen children, he is survived by Marilyn and
Frank, as well

as his sweetheart Nancy Roth, daughters Felicia Marie Deese & Carissa Ann
Murray, and

six grandchildren.  He enjoyed sailing, skiing, and traveling.

 

A memorial service will be on Saturday, August 27th at 11am at Andrews
Funeral Home,

7192 Main Street, Gloucester, VA.  In lieu of flowers, memorial donations
can be sent

to Hartfield Volunteer Fire Department.  Carpe Diem!

 

Professionally, Don was a true computer pioneer, and received the 1981 A. A.
Michelson

Award from the Computer Measurement Group for his development of techniques
to measure

early computer system performance (think response time); he created the
first Expert

System tool to automatically detect and diagnose performance anomalies.

 

Sadly,

 

Barry Merrill

 

 


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

Re: Initiator - Identify the List of Jobs

[Barry Merrill]

Ok, now that I know there is an appropriate SYSLOG message,
should I then add that MXG also can create an SMF record from
any SYSLOG message, as part of the 
MXG Tape Mount Monitor and SYSLOG Record SMF Recorder?

Barry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Wednesday, July 27, 2016 11:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Initiator - Identify the List of Jobs

On Wed, Jul 27, 2016 at 11:00 AM, Jake Anderson 
wrote:

> Hello,
>
> I am trying to fetch the List of Jobname that used a specific 
> Initiator. Is there a way to determine ?
>
> Is that again an SMF report would tell ?
>
> Jake
>

A
​s Doctor Merrill indicated, I don't think that "plain vanilla" SMF​ has this 
information. At my shop (no WLM initiators), I would scan the z/OS SYSLOG for 
the $HASP373 message and parse it. Seems a curious need to me.


--
Klein bottle for rent -- inquire within.

Maranatha! <><
John McKown

--
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: Initiator - Identify the List of Jobs

[Barry Merrill]

MXG Softare, long ago, provided code for IEFU84 Exit to populate
the Initiator Name and Number into the SMF 30 subtype 1 record:


Change 22.136  The SMF Exit code to put Initiator Name and Init Number
IEFU84 if the PROGRAM field in the SMF 30 subtype 1 record that
Jun 24, 2004   was announced in Change 19.269 now exists in the member
   IEFU84, which is the JOB to assemble that SMF exit. Your
   System Programmer will need to install the exit for you,
   as it must be placed in an authorized load library, and
   he/she will want to examine this SMF exit code.
   MXG member VMAC30 already has the code in place and will
   now populate the variables INITNAME and INITNUM after you
   have installed the IEFU84 exit to add the data to SMF 30.
   But note that only "real" initiators have names/numbers;
   WLM-managed initiators will have blank initname and no
   value for initiator number.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jake Anderson
Sent: Wednesday, July 27, 2016 11:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Initiator - Identify the List of Jobs

Hello,

I am trying to fetch the List of Jobname that used a specific Initiator. Is 
there a way to determine ?

Is that again an SMF report would tell ?

Jake

--
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: RDW corruption

[Barry Merrill]

Our output is VB  LRECL=31996  BLKSIZE=32000.
> Using BUFL=32600 fixes our problem.

It looks like your error is too small a BLKSIZE.

The maximum BLKSIZE for VB or VBS is 32760, NOT your 32000.

If BUFL=32600 then your use of BLKSIZE=32000 is short of the mark.

To read ANY VB file, use RECFM=VB,LRECL=32756,BLKSIZE=32760.

Barry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Joseph Reichman
Sent: Monday, July 18, 2016 2:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RDW corruption

I know my boss assigned me this problem As an aside if I register my IRS
e-mail on IBM-Main is there a way not get every e-mail I don't mind it in my
personel e-mail But I have a lot of other stuff on my irs.gov e-mail



> On Jul 18, 2016, at 3:21 PM, Campbell Jay 
wrote:
> 
> Have a current SR open with IBM...   57827 082 000
> Our output is VB  LRECL=31996  BLKSIZE=32000.
> Using BUFL=32600 fixes our problem.
> SR was opened to find out why that works.
> 
> Jay Campbell
> IBM OS Support Section
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] 
> On Behalf Of Joe Reichman
> Sent: Monday, July 18, 2016 3:17 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: RDW corruption
> 
> Hi,
> 
> 
> 
> I have a program that generates a corrupted RDW The file is a VB file. 
> I coded a synad exit but it didn't take (it was never given control)
> 
> 
> 
> When I go into ISPF and I do a max down I can see where ISPF can't read
the next record as I get "* * * I/O error detected, i/o terminated * * *"
> 
> 
> 
> As there anything/exit I can do to capture this the program seems to go to
> EOJ  
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

FW: Bsam VS Qsam for VB records

[Barry Merrill]

The original post had as noted below, two slashes,
but the ListServer rejected with:

Your  message is  being returned  to you  unprocessed because  it looks  like a 
LISTSERV command, rather than material intended for distribution to the members 
of the IBM-MAIN list. Please note that LISTSERV commands must always be sent to 
the LISTSERV address. If it was indeed  a command you were attempting to issue, 
then send it again to lists...@listserv.ua.edu for execution. Otherwise, please 
accept our apologies  and try to rewrite the message  with a slightly different 
wording -  for instance, change  the first word of  the message, enclose  it in 
quotation marks, insert a line of dashes at the beginning of your message, etc.


 THIS-IS-SLASH-SLASH  EXEC SAS
 THIS-IS-SLASH-SLASH  DATAFILE DD DSN=WHATEVER,DISP=SHR
 THIS-IS-SLASH-SLASH  SYSIN DD *
  DATA _NULL_;
  INFILE DATAFILE RECFM=U BLKSIZE=32760;
  INPUT;
  LIST;
  IF _N_ GT 10 THEN STOP;

will print a nice hex dump of each of the first 10 block.

Barry


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694

 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Tuesday, July 19, 2016 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bsam VS Qsam for VB records

On Tue, Jul 19, 2016 at 10:15 AM, Reichman Joseph <joseph.reich...@irs.gov>
wrote:

> With RECFM=U there is 1 record per block and the BDW is RDW + 4 ?
>

​Technically speaking, with RECFM=U there is not a BDW. There is just a bunch 
of bytes with no access method imposed interpretation. You must determine the 
number of bytes actually read by taking the number of bytes you requested to be 
read (the BLKSIZE basically) and subtract the CCW residual count to determine 
the number of bytes actually read. Luckily, IBM supplies an example.
ref:
http://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.idad400/len99.htm
​



>
> Joe Reichman
> Joe Reichman
>
> IT Specialist
> Master Files Division
> New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex 
> M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350
> Cell (917) 748-9693
> TOD M - F  7:30 am  - 4:00 pm
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] 
> On Behalf Of John McKown
> Sent: Tuesday, July 19, 2016 10:57 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: Bsam VS Qsam for VB records
>
> On Tue, Jul 19, 2016 at 9:54 AM, Pew, Curtis G < 
> curtis@austin.utexas.edu
> > wrote:
>
> > On Jul 19, 2016, at 9:39 AM, Reichman Joseph 
> > <joseph.reich...@irs.gov>
> > wrote:
> > >
> > > I am not thinking of moving this in production it may help me 
> > > track down
> > a problem
> >
> > If your motivation is to examine the physical blocks, why not read 
> > with QSAM specifying RECFM=U?
> >
>
> ​That is what I do, with: RECFM=U,LRECL=32756,BLKSIZE=32760 and then 
> use QSAM and "have fun".​ Or not, as the case may be.
>
>
>
> >
> > --
> > Pew, Curtis G
> > curtis@austin.utexas.edu
> > ITS Systems/Core/Administrative Services
> >
> > 
> > -- For IBM-MAIN subscribe / signoff / archive access instructions, 
> > send email to lists...@listserv.ua.edu with the message: INFO 
> > IBM-MAIN
> >
>
>
>
> --
> "Worry was nothing more than paying interest on a loan that a man may 
> never borrow"
>
> From: "Quest for the White Wind" by Alan Black
>
> Maranatha! <><
> John McKown
>
> --
> 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
>



--
"Worry was nothing more than paying interest on a loan that a man may never 
borrow"

From: "Quest for the White Wind" by Alan Black

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: Already logged on message - Wrong System ID

[Barry Merrill]

Dr Alan Scherr was the primary designer of TSO, and the team was working late 
nights (to get
better response!).  Late on the night when the product was due to be delivered 
to PID for
shipment, he had gone out for dinner, and when he came back, he logged on but 
was receiving
no messages back at his terminal, and commented, when one of the other members 
of the team
said "your messages are over here on the terminal you were using before dinner!"

Thus did Alan add an EXCLUSIVE ENQ on SYS1.UADS(YOURID) so that you could only 
be logged
on at one terminal, and thus met his PID delivery at 7am that morning.

Prior to creating TSO, he had modeled expected TSO response and when the 
product failed to match his model, HE CHANGED THE PRODUCT to match the model, 
not the model.



Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jake Anderson
Sent: Thursday, July 14, 2016 8:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Already logged on message - Wrong System ID

Hi Liz,

"Did  you logon to LPAR2 and forget to logoff when you tried to logon to LPAR1?"


You are correct.. So this become a pain when we try to logon other LPARs in 
sysplex without being aware of Our ID logged on to the other System.

On Thu, Jul 14, 2016 at 7:01 PM, Lizette Koehler <stars...@mindspring.com>
wrote:

> Jake,
> Some additional details will help
>
> Are you using a session manager?
> Are you logging on with an APPL (LOGON APPL() ) command?
>
> Have you verified your definitions for the two lpars are set up 
> correctly?  Did you code LPAR1 Appl for LPAR2 and so forth?
>
> Please provide a display of your session definitions for TSO D 
> NET,ID=,E
>
> You need to make sure all of your connection definitions are correct 
> first before looking to MIM.  I am not aware of how MIM might affect a logon.
>
> A Session manage could affect your logon.
>
> If all connections are correct, then check how your TSO environment is 
> set up.  Are your ISPF datasets (like PROFILE) unique?  Do you have a 
> logon CLIST/REXX that allocates unique files?
>
> Did  you logon to LPAR2 and forget to logoff when you tried to logon 
> to LPAR1?
>
>
>
> Lizette
>
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake Anderson
> > Sent: Thursday, July 14, 2016 4:38 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Already logged on message - Wrong System ID
> >
> > Hello,
> >
> > I am trying to access one of an LPAR1 within a sysplex. Where I get 
> > a
> message
> > as you already logged on to LPAR1. When I have someone to check my 
> > ID
> from
> > other system its shows that My ID is active in LPAR2.
> >
> > We have MIM but we have not enabled Parallel Logon facility
> serialization.
> >
> > I am curious why z/OS is displaying a wrong System Name instead of 
> > the
> One my
> > ID is active ?
> >
> > Its like I am logged into LPAR2, but when I try accessing LPAR1, it
> shows that
> > you are already logged on to LPAR1..
> >
> > This gets resolved after My ID is cancelled from LPAR 2.
> >
> > Are there any EXITS or REXX which can tell me the correct System 
> > Name
> when I
> > try to logon to other LPAR within the same sysplex(Shared RACF and 
> > no MIM serialization).
> >
> > Did any of you face this kind of situation and found a remedy ?(Here 
> > in
> our
> > MIM serialization for IKJUA IS not allowed)
> >
> >
> >
> > Jake
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

FW: Where is format of Job ID documented?

[Barry Merrill]

One addition for the archives for this thread:

 SMF 6 records written by PRINTWAY/INFOPRINT BASIC Mode contain
JCTJOBID='PSnn'.

 (which could be confused with type 6 records written by PSF, which contain
PSFn).

Barry


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694

 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Barry Merrill
Sent: Wednesday, June 15, 2016 3:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where is format of Job ID documented?

NO, but MXG has discovered these possibilities:


/* THIS ROUTINE EXPECTS JCTJOBID AND JOB AS 8-BYTE CHARACTERS, */
 /* AND SUBSYS AS A 4-BYTE CHARACTER AS INPUT.  */

 /* JCTJOBID OF ONE LETTER AND 7 DIGITS EXIST, BUT THE MAXIMUM  */
 /* JESNR IS 99 BECAUSE THE 1ST WHEN SEVEN IS ALWAYS ZERO.  */

 /* IT CREATES THE 4-BYTE CHARACTER TYPETASK AND NUMERIC JESNR  */
 /* IT IS %INCLUDE-D AFTER JCTJOBID AND SUBSYS EXIST.   */

 TYPETASK='';
 JESNR=.;
 IF SUBSYS=''  THEN SUBSYS=''; /*EARLY ASIDS,TMNT */
 IF JCTJOBID=JOB OR (JCTJOBID LE ' ' AND SUBSYS='STC')
 OR (JCTJOBID EQ 'MSTR' AND SUBSYS='SMS') THEN DO;
   JESNR=.;
   TYPETASK='STC';
 END;
 ELSE DO;
   IF INPUT(SUBSTR(JCTJOBID,2,7),?? 7.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,2,7),?? 7.);
 TYPETASK=SUBSTR(JCTJOBID,1,1);
   END;
   ELSE IF INPUT(SUBSTR(JCTJOBID,3,6),?? 6.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,3,6),?? 6.);
 TYPETASK=SUBSTR(JCTJOBID,1,2);
   END;
   ELSE IF INPUT(SUBSTR(JCTJOBID,4,5),?? 5.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,4,5),?? 5.);
 TYPETASK=SUBSTR(JCTJOBID,1,3);
   END;
   ELSE IF INPUT(SUBSTR(JCTJOBID,5,4),?? 4.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,5,4),?? 4.);
 TYPETASK=SUBSTR(JCTJOBID,1,4);
   END;
   IF SUBSYS='TCP ' THEN TYPETASK='TCP ';
   ELSE IF SUBSYS='PSF ' THEN TYPETASK='PSF ';
   ELSE IF SUBSYS='VPS ' THEN TYPETASK='VPS ';
   ELSE IF TYPETASK=:'J' THEN DO;
 IF  SUBSYS='TSO ' THEN TYPETASK='TSU ';
 ELSE IF SUBSYS='JES2' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='JES3' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='STC ' THEN TYPETASK='STC ';
 ELSE IF SUBSYS='OMVS' THEN TYPETASK='OMVS';
 ELSE   TYPETASK='JOB ';
   END;
   ELSE IF TYPETASK=:'O' OR SUBSYS='OMVS' THEN TYPETASK='OMVS';
   ELSE IF TYPETASK=:'G' THEN TYPETASK='JOBG';
   ELSE IF TYPETASK=:'S' THEN TYPETASK='STC ';
   ELSE IF TYPETASK=:'A' THEN TYPETASK=SUBSYS;/*ASCH-OR-OMVS:CH16.150*/
   ELSE IF TYPETASK=:'T' THEN TYPETASK='TSU ';
   ELSE IF TYPETASK=:'I' AND SUBSYS='STC' THEN TYPETASK='STC  ';
   ELSE DO;
 IF  SUBSYS='STC ' THEN TYPETASK='STC ';
 ELSE IF SUBSYS='TSO ' THEN TYPETASK='TSU ';
 ELSE IF SUBSYS='JES2' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='JES3' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='STC ' THEN TYPETASK='STC ';
 ELSE IF SUBSYS='OMVS' THEN TYPETASK='OMVS';
 ELSE DO;
   IF PRODUCT='' THEN PRODUCT='';;
   IF SUBTYPE=.  THEN SUBTYPE=.;
   IF PRODUCT='PERFMON ' AND SUBTYPE=3 THEN DO;
 TYPETASK='STC';
 SUBSYS='PERFMON';
   END;
 END;
   END;
   IF TYPETASK=' ' THEN DO;
 BADVJESN+1;
 IF BADVJESN LE 2 THEN
   PUT '*** WARNING - TYPETASK NOT DECODED: ' /  +10
   _N_= SYSTEM= ID= SUBTYPE= JOB=
   JCTJOBID= SUBSYS= TYPETASK= JESNR= ;
   END;
   
 END;
  /* END OF MEMBER VGETJESN - GET JESNR AND TYPETASK FROM JCTJOBID */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Wednesday, June 15, 2016 3:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Where is format of Job ID documented?

Yeah, I know, JOBn or Tnnn.

Is there a formal description somewhere? Where?

Charles 

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

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

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

Re: Where is format of Job ID documented?

[Barry Merrill]

 FWIW, this old change does document the actual existence of JCTJOBID='A':

 Change 08.224  Support for MVS/ESA 4.2 (RMF 4.2.1).
 Jan 28, 1991

   d. The JCTJOBID field from which TYPETASK and JESNR are
  extracted has changed with APPC.  Instead of three
  characters JOB/STC/TSU follwed by the five digit JESNR
  the JCTJOBID will contain an "A" and a seven digit
  number, which MXG stores in TYPETASK and JESNR, but
  the maximum JESNR is 999,999 because the first of the
  seven digits is always a zero.  You should check if
  any reporting programs use TYPETASK for selection, and
  to ensure they are coded robustly so they will not
  fail if TYPETASK='A' is encountered.  The JCTJOBID
  change was not compatibly implemented and changed
  VMAC6,VMAC30,VMAC32,VMAC26J2, and VMAC26J3.  SMF
  records use the fieldname SMFnnJNM for the eight byte
  JCTJOBID field.  This IBM change in that field could
  also affect "banner page" printing code in your SMF
  exits.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Zelden
Sent: Sunday, June 19, 2016 1:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where is format of Job ID documented?

On Sat, 18 Jun 2016 21:00:38 +, Jesse 1 Robinson  
wrote:

>How could I determine if APPC output is clogging my spool? I don't see any at 
>the moment. 

Set PREFIX=* ,  DEST= (null)  and OWNER=* in SDSF.

Issue "H ALL"  and sort on JOBID and look for Annn Issue "O" and sort on 
JOBID and look for Annn

This assumes you don't have any SDSF parms or SDSF SAF security rules 
preventing you from seeing the output.  

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 
Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: 
http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
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: Where is format of Job ID documented?

[Barry Merrill]

NO, but MXG has discovered these possibilities:


/* THIS ROUTINE EXPECTS JCTJOBID AND JOB AS 8-BYTE CHARACTERS, */
 /* AND SUBSYS AS A 4-BYTE CHARACTER AS INPUT.  */

 /* JCTJOBID OF ONE LETTER AND 7 DIGITS EXIST, BUT THE MAXIMUM  */
 /* JESNR IS 99 BECAUSE THE 1ST WHEN SEVEN IS ALWAYS ZERO.  */

 /* IT CREATES THE 4-BYTE CHARACTER TYPETASK AND NUMERIC JESNR  */
 /* IT IS %INCLUDE-D AFTER JCTJOBID AND SUBSYS EXIST.   */

 TYPETASK='';
 JESNR=.;
 IF SUBSYS=''  THEN SUBSYS=''; /*EARLY ASIDS,TMNT */
 IF JCTJOBID=JOB OR (JCTJOBID LE ' ' AND SUBSYS='STC')
 OR (JCTJOBID EQ 'MSTR' AND SUBSYS='SMS') THEN DO;
   JESNR=.;
   TYPETASK='STC';
 END;
 ELSE DO;
   IF INPUT(SUBSTR(JCTJOBID,2,7),?? 7.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,2,7),?? 7.);
 TYPETASK=SUBSTR(JCTJOBID,1,1);
   END;
   ELSE IF INPUT(SUBSTR(JCTJOBID,3,6),?? 6.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,3,6),?? 6.);
 TYPETASK=SUBSTR(JCTJOBID,1,2);
   END;
   ELSE IF INPUT(SUBSTR(JCTJOBID,4,5),?? 5.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,4,5),?? 5.);
 TYPETASK=SUBSTR(JCTJOBID,1,3);
   END;
   ELSE IF INPUT(SUBSTR(JCTJOBID,5,4),?? 4.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,5,4),?? 4.);
 TYPETASK=SUBSTR(JCTJOBID,1,4);
   END;
   IF SUBSYS='TCP ' THEN TYPETASK='TCP ';
   ELSE IF SUBSYS='PSF ' THEN TYPETASK='PSF ';
   ELSE IF SUBSYS='VPS ' THEN TYPETASK='VPS ';
   ELSE IF TYPETASK=:'J' THEN DO;
 IF  SUBSYS='TSO ' THEN TYPETASK='TSU ';
 ELSE IF SUBSYS='JES2' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='JES3' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='STC ' THEN TYPETASK='STC ';
 ELSE IF SUBSYS='OMVS' THEN TYPETASK='OMVS';
 ELSE   TYPETASK='JOB ';
   END;
   ELSE IF TYPETASK=:'O' OR SUBSYS='OMVS' THEN TYPETASK='OMVS';
   ELSE IF TYPETASK=:'G' THEN TYPETASK='JOBG';
   ELSE IF TYPETASK=:'S' THEN TYPETASK='STC ';
   ELSE IF TYPETASK=:'A' THEN TYPETASK=SUBSYS;/*ASCH-OR-OMVS:CH16.150*/
   ELSE IF TYPETASK=:'T' THEN TYPETASK='TSU ';
   ELSE IF TYPETASK=:'I' AND SUBSYS='STC' THEN TYPETASK='STC  ';
   ELSE DO;
 IF  SUBSYS='STC ' THEN TYPETASK='STC ';
 ELSE IF SUBSYS='TSO ' THEN TYPETASK='TSU ';
 ELSE IF SUBSYS='JES2' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='JES3' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='STC ' THEN TYPETASK='STC ';
 ELSE IF SUBSYS='OMVS' THEN TYPETASK='OMVS';
 ELSE DO;
   IF PRODUCT='' THEN PRODUCT='';;
   IF SUBTYPE=.  THEN SUBTYPE=.;
   IF PRODUCT='PERFMON ' AND SUBTYPE=3 THEN DO;
 TYPETASK='STC';
 SUBSYS='PERFMON';
   END;
 END;
   END;
   IF TYPETASK=' ' THEN DO;
 BADVJESN+1;
 IF BADVJESN LE 2 THEN
   PUT '*** WARNING - TYPETASK NOT DECODED: ' /  +10
   _N_= SYSTEM= ID= SUBTYPE= JOB=
   JCTJOBID= SUBSYS= TYPETASK= JESNR= ;
   END;
   
 END;
  /* END OF MEMBER VGETJESN - GET JESNR AND TYPETASK FROM JCTJOBID */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Wednesday, June 15, 2016 3:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Where is format of Job ID documented?

Yeah, I know, JOBn or Tnnn.

Is there a formal description somewhere? Where?

Charles 

--
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: Video that might give you a chuckle

[Barry Merrill]

I had so many 0Charlie4 "friends" during very early MVS testing in 1976 that I 
knew them as 0-CHUCK-4's;
found out later the sysprogs called me "Chuck" behind my back, presumably as I 
was out of step??

Barry Merrill 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Friday, May 27, 2016 9:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Video that might give you a chuckle

On Fri, May 27, 2016 at 9:23 AM, Vernooij, CP (ITOPT1) - KLM < 
kees.verno...@klm.com> wrote:

> Did you ever have a Sock4?
>
> Yes, you did, but you will know it as a SOC4 abend.
>
> Kees.
>
>
​I'll see your sock4 and raise you a sock7. Back in the days of static linking, 
we got a lot of sock1s. Being bipedal, you'd think we would get sock2s, but 
that's a different thing altogether.

It's a weird Friday before a 3 day weekend here in the States.​



--
The unfacts, did we have them, are too imprecisely few to warrant our certitude.

Maranatha! <><
John McKown

--
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: CREATED date for migrated data sets?

[Barry Merrill]

I think its worse than that.

Change 34.115  Variable DCDTIMEC, Data Set Create Time in DCOLDSET is
VMACDCOL   only populated if
May 11, 2016 - the dataset is on an EAV volume (more than 65K CYL)
 - the volume is the first volume for the dataset
   (DCDTIMEC is zero in the DSCB for other volumes)
 - for non-VSAM, EATTR=OPT must be specified (JCL or
   Data Class), because EATTR=NO is the default for
   non-VSAM, EATTR=OPT is the default for VSAM.
   The DCDTIMEC comes from the FORMAT 9 DSCB control block
   (in the VTOC), created for EAS-eligible datasets on EAV
   that have EATTR=OPT, except for datasets that do not have
   do not have FORMAT 8/9 DSCBs.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, May 26, 2016 2:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CREATED date for migrated data sets?

I would like to HRECALL all data sets matching a certain pattern and created 
since 2016-04-01.  Alas, ISPF DSLIST does not show created date for migrated 
data sets.

I suppose that if they were created after April 1, they could not have been 
migrated earlier, so I could use a HLIST.  Is there a better way?

Thanks,
gil

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

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

Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

[Barry Merrill]

I added support in 2014 but have not had a motivation to create 999 and see 
what happens!

  -VMACCTLG and VMAC6156 were updated Nov 27, 2014.
   Support for GDGE, GDG Extended GDGLIMIT=999 in z/OS 2.2.
   New variable GATEXTND='E' flags the extended mode, new
   variables GATLIMTE/GATCNTE are INPUT but also kept in the
   existing GATLIMIT/GATCNT to preserve existing reports.
   Some overlooked flag variables in the 05 Catalog Segment
   are now decoded and kept in datasets TYPE6156 (from SMF
   (type 61, 65, 66) and TYPECTLG (from the IDCAMS EXPORT
   CATALOG flat file).  These are all the 05 fields now:
 GATALLOC='GATALLOC*FIFO OR*LIFO?'
 GATCNT  ='GDG*COUNT'
 GATDELET='DELETE*WHEN*LIMIT*EXCEEDED*0=OLD*1=ALL?'
 GATEXTND='GATEXTND*EXTENDED*OR CLASSIC?'
 GATEXTNO='GATEXTNO'
 GATGEN  ='GATGEN  '
 GATLIMIT='MAXIMUM*GDS*ENTRIES*IN GDG*BASE'
 GATLIMTE='EXTENDED*GAT*GATLIMIT'
 GATPURGE='GATPURGE*YES OR*NO?'
 GATSCRTH='SCRATCH*FORMAT 1*DSCB*0=NO*1=YES?'
 GATVER  ='GATVER  '
 GATWRAP ='GATWRAP '
 GDGATTR ='GDGATTR'
  -BUILD005 protects for TYPETASK='JOBG' in JCTJOBID;

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, May 26, 2016 9:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

Barry,

I have heard that the number of GDGs may be allowed to go beyond 255 
generations. Do you have any insight on this?  I am wondering how this 
enhancement may impact the GDG Wrap condition.



I have seen in the z/OS V2.2 manuals:

Extended format for generation data groups (GDGs):

z/OS V2R2 introduces a new extended format for generation data groups (GDGs). 
Extended format GDGs can contain up to 999 generation data sets (GDSes). The 
previous GDS limit was 255 GDSes per GDG. New GDGs can be defined with this new 
extended format. For existing GDGs, the previous GDS limit still applies.

To support this enhancement, the IDCAMS DEFINE GDG command includes a new 
optional parameter (EXTENDED) that you can specify to enable a new GDG to 
contain up to 999 GDSes. If you do not specify that parameter, the default 
value (NOEXTENDED) takes effect, setting a limit of 255 GDSes for the GDG.

A new GDGEXTENDED parmlib variable lets you specify whether to allow the 
EXTENDED value to be used on DEFINE of a GDG. If GDGEXTENDED(NO) (the default) 
is specified, then the DEFINE of a GDG with the EXTENDED parameter is not 
allowed. If GDGEXTENDED(YES) is specified, then the DEFINE of a GDG with the 
EXTENDED parameter is allowed. For more information, see the description of 
IGGCATxx in z/OS MVS Initialization and Tuning Reference.

The LIMIT parameter on the IDCAMS DEFINE GDG command is changed to accept a 
maximum value of 999 for extended GDGs. The previous maximum LIMIT value of 255 
still applies to GDGs which are not defined as EXTENDED.

For extended GDGs, the IDCAMS ALTER LIMIT command is also enhanced to let you 
set a new GDS limit of up to 999 for the GDG. The z/OS Generic Tracking 
Facility has also been used to help determine if any calls to Catalog 
Management are only requesting the classic GDG limit, and not the extended GDG 
limit.

For more details about these enhancements, see the descriptions of the ALTER 
command and the DEFINE GENERATIONDATAGROUP command in z/OS DFSMS Access Method 
Services Commands.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Barry Merrill
> Sent: Thursday, May 26, 2016 7:44 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Proper way to resolve existing GDG GnnnVnnn by relative 
> reference
> 
> An old change in MXG Software:
> 
> 
> Change 23.219  The ICF Catalog 05 record variable GATGEN should have
> VMAC6156   been input as , instead of one byte, and variable
> VMACCTLG   GATWRAP='Y' is now set if the first bit of GATGEN is on,
> Aug 29, 2005   to mark that this GDG member has "wrapped"; i.e., its
>generation number has exceeded .  If GATWRAP is on,
>GATGEN=GATGEN-32768 to contain the correct Gen number.
>This discovery was precipitated by IGD07001I ABENDs in
>production, which occurred when a GDG that had GATWRAP
>on for some members, and GATWRAP off for others, when
>that GDG generation number goes from 999 to 1000.
>  Normally, when all members of a GDG have wrapped, the
>  next catalog action turns off the

Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

[Barry Merrill]

An old change in MXG Software:


Change 23.219  The ICF Catalog 05 record variable GATGEN should have
VMAC6156   been input as , instead of one byte, and variable
VMACCTLG   GATWRAP='Y' is now set if the first bit of GATGEN is on,
Aug 29, 2005   to mark that this GDG member has "wrapped"; i.e., its
   generation number has exceeded .  If GATWRAP is on,
   GATGEN=GATGEN-32768 to contain the correct Gen number.
   This discovery was precipitated by IGD07001I ABENDs in
   production, which occurred when a GDG that had GATWRAP
   on for some members, and GATWRAP off for others, when
   that GDG generation number goes from 999 to 1000.
 Normally, when all members of a GDG have wrapped, the
 next catalog action turns off the wrap bit in all of
 the catalog records.  For a "normal" GDG, that should
 happen when the +256th gen is created after wrap, as
 only 255 members can exist in the catalog.  But this
 site had had a very old application that originally
 created +1 thru +5 each day, and then deleted +1 thru
 +4, leaving only +5 in the catalog.  However, back when
 Clinton was President, an application change was made
 that created only +1 thru +3 and deleted only +1 & +2,
 so there were 2 old GVoo's left in the catalog.
 When the GDG wrapped, and when the create of +1 would
 have created G1000V00, those old GVoo's still had
 their wrap bit off, and the production job failed:
   IGD07001I; GDG ROLL IN ERROR - RETURN CODE 140 REASON 122
 Return Code 140:
   Inconsistent or conflicting arguments were provided.
 Reason Code 122:
   Catalog G1000Vxx will cause the GDG to exceed the
   limit of 10,999.
 Programmer Response:
   Clean up the GDG in error then catalog G1000Vxx.
   The site found Information APAR II07276, which explained
   how wrap works, but it says to 'see the "Z" page for
   internal details of the wrap bit interface'.

   So the site asked IBM Support: "We need to identify other
   GDGs that have the same exposure to causing ABENDs.  Can
   I look at the 'Z' page?  Does the 'wrap bit' appear in
   SMF 61, 65, 66 ICF Catalog records?"

   IBM Level 2 Catalog Support refused to answer the quite
   valid question, with this answer:
 "Unfortunately, the 'Z' page in our info APARs refer to
 information meant for IBM eyes only, for helping us get
 to problem determination quicker.  We are not at
 liberty to discuss any control block internals that are
 not provided in our published manuals.  As for
 information in SMF records relating to this, this info
 would be included in the updated record portion
 of the SMF record, however we cannot discuss offsets
 for those either.  I am sorry I cannot be more helpful.
 Please let me know if there are any other questions
 that I can answer for you."

   Even escalation to my IBM Poughkeepsie z/OS support did
   not convince IBM Level 2 Catalog Support to identify
   which bit is the "GATWRAP" bit.  The ICF Support and
   Developers hid behind "OCO", Object Code Only, as the
   reason they could not provide catalog record
   documentation (but DSECTS are NOT CODE!).

   So I suggested the site could create a GDG and force it
   to wrap, and by examining SMF records, we concluded that
   first bit of GATGEN was the GATWRAP bit.

   Then, I remembered I still had lots of archaic printed
   manuals, and located the very old "MVS/XA Catalog
   Diagnosis Reference for DFP Release 1.2", which confirmed
   that the GATWRAP bit was indeed the first bit of the
   GATGEN field in the 05 Catalog Record!

Barry Merrill



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Thursday, May 26, 2016 8:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

On Wed, May 25, 2016 at 6:37 PM, Lizette Koehler <stars...@mindspring.com>
wrote:

> John,
>
> Would this code account for a V01 - V99 ending in the GDG?
> And would it handle the fact that the next GDG might not be 

Re: What does it indicate when an SMF 30 subtype 4 or 5 has no completion section?

[Barry Merrill]

Not true; there will be the JES 26 Purge Record for the job,
and you can tell it's a JCL error because the STARTIME will
be missing (job never passed to z/OS) and possibly the CONVERTERTIME
will also be missing (depending on the JCL error).

Barry
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Wednesday, May 18, 2016 9:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What does it indicate when an SMF 30 subtype 4 or 5 has no
completion section?

> 2) "Continuation record" due to "record too large conditions. I.e. due
multiple unconsolidated DD statements.

Yup. Thanks.

> 1) STEP was "flushed" due to JCL error or COND= processing.

Nope. If the job was flushed due to a JCL error no SMF record is cut. If the
step was flushed due to COND= then there is a completion section. The
indicator bit X'0100' is on and the completion and reason code fields are
zero.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Staller, Allan
Sent: Wednesday, May 18, 2016 5:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What does it indicate when an SMF 30 subtype 4 or 5 has no
completion section?

1) STEP was "flushed" due to JCL error or COND= processing.
2) "Continuation record" due to "record too large conditions. I.e. due
multiple unconsolidated DD statements.

Check the SMF manual for the gory details..

HTH,

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

FW: SMF dump processing

[Barry Merrill]

When I looked as some old SYSLOG data, it appears there can be several events 
that may occur between the IEC205 message
and the IEC234K Keep Message for the same job.  No real delay in this example, 
but it does show events.

(And ONLY after the accidental selection of this by message sequence and JES 
NR, did I note the example happens
to be an MXG job!!).



M 002 SYSK 2007114 00:51:10.09 JOB06647 0084  IEC205I 
BACKUP,XXXTDUHS,SAS,FILESEQ=1, COMPLETE VOLUME LIST, 666
E   666 0084  
DSN=XXX0.MXG.PDB.HSM.BACKUP.G1672V00,VOLS=D59438,TOTALBLOCKS=25805
N 002 SYSK 2007114 00:51:10.29 JOB06647 0084  ACF99900 ACF2 
LOGGING-08,05,SCHPROD,D59438,XXX0.MXG.PDB.HSM.BACKUP
S .G1672V00,N/A
N 0004000 SYSK 2007114 00:51:10.40 JOB06647 0284  -XXXTDUHS PS030
SAS 00  394241.64.016.1 12790K
S   0  0  0 
 0 0
N 000 SYSK 2007114 00:51:10.45 JOB06647 0280  OPS1370H INIT 
X'4000' X'' X'' NONE  300 ATM$TAP3
S TAP3M02: take_one 
TDUHS - var ZZZTEMPT.TAPES.UNITS.XXXTDUHS
N 400 SYSK 2007114 00:51:10.45 JOB06647 0084  ATM$TAP3 TAP3M02: 
take_one XXXTDUHS - var ZZZTEMPT.TAPES.UNITS.XXXTDUHS
S S.E351 deleted
N 200 SYSK 2007114 00:51:10.44 JOB06647 0080  TMS014  IEF234E K 
E351,D59438,PVT,XXXTDUHS
N 200 SYSK 2007114 00:51:10.44 JOB06647 00080084  IEF234E K 
E351,D59438,PVT,XXXTDUHS



Barry 


Herbert W. “Barry” Merrill, PhD
President-Programmer
MXG Software
Merrill Consultants
10717 Cromwell Drive
Dallas, TX 75229-5112
ba...@mxg.com
Fax:  214 350 3694 – Still works, received as email
Tel:  214 351 1966 – Unreliable, please use email

www.mxg.comHomePage: FAQ answers most questions
ad...@mxg.com  License Forms, Invoice, Payment, ftp information
supp...@mxg.comTechnical Issues 
MXG-L FREE ListServer  http://www.mxg.com/mxg-l_listserver/




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Zelden
Sent: Thursday, April 14, 2016 2:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMF dump processing

On Thu, 14 Apr 2016 19:12:12 +, Staller, Allan 
<allan.stal...@wunderman.com> wrote:

>Are you recording  SMF 19? IIRC this can greatly elongate the SMF dump process 
>as the system goes to touch every online volume for each SMF dataset switch.
>

Right - at SMF switch time.  But the problem seems to be at the end of the 
dump.  Almost as
if it was taking 15 minutes to to rewind a physical tape.   At least that seems 
to be the problem 
as it was described.

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 
Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: 
http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
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: RLSE does not work with PGM=FTP

[Barry Merrill]

Thanks, John, that solved the problem.

Barry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Sunday, April 03, 2016 11:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RLSE does not work with PGM=FTP

On Sun, 3 Apr 2016 21:11:59 -0500, John McKown wrote:
>
>​Dr. Merrill,
>I know that I'm not in your league. But it looks to me like what you're 
>doing is allocating a DSN using JCL, but directing the FTP process to 
>write to it using dynamic allocation. So you never really open the DD 
>INFILE or do a CLOSE on it. IIRC, RLSE is done by the CLOSE operation. 
>Shouldn't your GET look more like:
>
>GET CICS2.terse +
>//DD:INFILE​ (replace
> 
And, perhaps likewise irritating, I've discovered that overriding DCB 
attributes in the DD statement are ineffective.  FTP will use those in the DSCB 
regardless.

-- gil

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

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

RLSE does not work with PGM=FTP

[Barry Merrill]

Using IBM FTP CS V2R1, the uploaded INFILE's excess space is not RLSE'd.

 

//FTPUP EXEC PGM=FTP,PARM='(EXIT=4'

//SYSPRINT DD SYSOUT=*,DCB=BLKSIZE=133

//SYSABEND DD SYSOUT=*

//SYSOUT   DD SYSOUT=*

//FTPOUT   DD SYSOUT=*

//INFILE   DD DSN=MXGLRG.CICS.UNTERSE,DISP=(NEW,CATLG,CATLG),

//UNIT=(3390,1),DSNTYPE=LARGE,

//DSORG=PS,RECFM=FB,LRECL=1024,BLKSIZE=6144,

//SPACE=(CYL,(500,500),RLSE)

//SYSINDD *

99.99.99.99

USERID   PASSWORDPHRASE

BINARY

GET CICS2.terse +

  'MXGLRG.CICS.UNTERSE' (replace

CLOSE

QUIT

 

I found one reference that CLOSE TYPE=T prevents RLSE, but no reference

if FTP uses TYPE=T.   

 

 

Barry

 

 

Herbert W. "Barry" Merrill, PhD

President-Programmer

MXG Software

Merrill Consultants

10717 Cromwell Drive

Dallas, TX 75229-5112

ba...@mxg.com <mailto:ba...@mxg.com> 

Fax:  214 350 3694 - Still works, received as email

Tel:  214 351 1966 - Unreliable, please use email

 

www.mxg.com <http://www.mxg.com> HomePage: FAQ answers most
questions

ad...@mxg.com <mailto:ad...@mxg.com>   License Forms, Invoice, Payment,
ftp information

supp...@mxg.com <mailto:supp...@mxg.com> Technical Issues 

MXG-L FREE ListServer  http://www.mxg.com/mxg-l_listserver/

 


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

Re: Reading the CA-1 Tape Catalog

[Barry Merrill]

And MXG's recommendation is 


4. DCB attributes of TMC records need large BUFNO.

 The TMC records are Fixed Length LRECL=340.  If reading under MVS, use
 very large BUFNO=220 to significantly reduce processing time.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of retired mainframer
Sent: Friday, February 12, 2016 12:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Reading the CA-1 Tape Catalog

If you are going to use QSAM to read the TMC, remember that while the file
is FB with LRECL 340, there are at least three different internal record
formats: control records, volume records, and DSNB records (which are
actually 170 bytes and therefore "blocked" 2 per "QSAM record").

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Hardee, Chuck
> Sent: Friday, February 12, 2016 5:58 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Reading the CA-1 Tape Catalog
> 
> Thanks Russell, I'll go re-read the documentation in the programming
guide.

--
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: Even after all the Y2K work....

[Barry Merrill]

SAS is aware:

data; date='29FEB2100'D; day=weekday(date); put day=;run;
  
  77
ERROR: Invalid date/time/datetime constant '29FEB2100'D.

ERROR 77-185: Invalid number conversion on '29FEB2100'D.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Russell Witt
Sent: Wednesday, February 10, 2016 11:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Even after all the Y2K work

The one date I wish I could be around to see is March 1st, 2100. That will be 
the first year since 1900 when the old standard "every 4 years" does NOT apply. 
No Feb 29th in 2100. But that date I don't have to worry about.

Russell 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Roach, Dennis
Sent: Wednesday, February 10, 2016 12:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Even after all the Y2K work

If you try the 28th it says it is on Sunday. March 1st it says is on Tuesday. 
Both are correct. Monday just doesn't exist.


Dennis Roach, CISSP, PMP
IAM Access Administration – Consumer – Senior Analyst
2727 Allen Parkway, Wortham Building 3rd Floor, Houston, TX 77019
Work:  713-831-8799
Cell:  713-591-1059
Email:  dennis.ro...@aig.com 

--
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: Identifying creator of SMF records

[Barry Merrill]

In general, you have to rely on a hex dump of a few of the user SMF records,
to look for obvious fields and contents, and ask your SYSPROGs/DBAs etc,
what products are installed.  
Sometimes there is a SUBSYSTEM ID that identifies the creator in bytes 15-18.  
You can identify lots of EBCDIC text fields by content and length, like the 
JOB, USERID, JCTJOBID, 44-byte DSNAMES, RACFGRUP names, the SMFSTAMP and 
TODSTAMP datetime fields, and along with asking what products are installed,
you can often identify the creator and find the SYSPROG who chose that SMF
record type to confirm!

But often the final identification requires visual examination 
of the record's hex dump, and to count the recognizable elements
(e.g., 2 DSNAMEs, 3 TODSTAMP, 2 SMFSTAMP, JOB JCTJOBID), and then 
examine a possible product's source member in MXG to count those
same elements in the SAS INPUT statements to find a match, and
then confirm by comparing field-by-field visually, or just
by using that MXG code member to read the record.

MXG has only 260 user SMF record members to examine.


Barry


Herbert W. “Barry” Merrill, PhD
President-Programmer
MXG Software
Merrill Consultants
10717 Cromwell Drive
Dallas, TX 75229-5112
ba...@mxg.com
Fax:  214 350 3694 – Still works, received as email
Tel:  214 351 1966 – Unreliable, please use email

www.mxg.comHomePage: FAQ answers most questions
ad...@mxg.com  License Forms, Invoice, Payment, ftp information
supp...@mxg.comTechnical Issues 
MXG-L FREE ListServer  http://www.mxg.com/mxg-l_listserver/









-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Friday, January 22, 2016 6:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Identifying creator of SMF records

Alan,

I think the better forum with be either the MICS Community on CA website or 
MXG.COM 

If you have SAS and MXG or SAS and MICS, one of them might have a cross 
reference or way to determine SMF details.

I have usually maintained a text file in SYS1.PARMLIB that contains a list of 
either SVCs or SMF records for non IBM products.

If you do not have that, then you may have to find another way.  And I am not 
sure how that can be done if you do not have the ability to search any and all 
installation libraries for vendor products to see what pops up.

Sometimes shops will use the defaults supplied by the Vendors and that will be 
documented in the vendors installation manual.  So I would start with that.



Lizette



-Original Message-
>From: "Field, Alan" <alan.fi...@bluecrossmn.com>
>Sent: Jan 22, 2016 2:30 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Identifying creator of SMF records
>
>Is there a way to identify what is creating user written SMF records?
>
>We have 210s, 230s and 254s that we can't identify the source.
>
>We've dumped the records and looked at them. Some give hints (e.g. the 230s 
>look like perhaps CA OpsMVS, the 254s perhaps something related to SAF).
>
>TIA
>
>Alan

--
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: Change CPC name in HMC

[Barry Merrill]

SMF 106 Subtype 1, SMF6ACPC, 17-characters.

Barry


Herbert W. "Barry" Merrill, PhD
President-Programmer
MXG Software
Merrill Consultants
10717 Cromwell Drive
Dallas, TX 75229-5112
ba...@mxg.com
Fax:  214 350 3694 - Still works, received as email
Tel:  214 351 1966 - Unreliable, please use email

www.mxg.comHomePage: FAQ answers most questions
ad...@mxg.com  License Forms, Invoice, Payment, ftp information
supp...@mxg.comTechnical Issues 
MXG-L FREE ListServer  http://www.mxg.com/mxg-l_listserver/




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Martin Packer
Sent: Thursday, January 07, 2016 10:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Change CPC name in HMC

What SMF records contain the CPC name?

Thanks, Martin

Martin Packer,
zChampion, Principal Systems Investigator, Worldwide Cloud & Systems
Performance, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   Skip Robinson <jo.skip.robin...@att.net>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   07/01/2016 15:49
Subject:Re: Change CPC name in HMC
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



First off, you can name a CPC anything you want within the syntax rules. 
Ideally you should pick a good name at initial install, but it can be
changed later. That being said, after we installed z12s in a new data center
in 2013, we intended to rename the z196 remaining in the old data center. We
never got that done because we had never actually renamed a box before and
were wary of what it would take to accomplish without disruption. Nothing
crucial depended on a rename, so we shined it on. The name is embodied in
two places:

-- The IODF names all processors.
-- The HMC/SE names each processor in several places from POR (Reset)
profile onward. 

IODF and HMC must agree. For a new box, this is not so hard. The trick is
make a change without hosing up the environment. Also consider other
implications:

-- BCPii must also be updated. I consider that part of the HMC/SE tasks
above, but don't overlook it.
-- POR will be required.
-- SMF records contain the CPC name. Any post processing must take a change
into account.
-- It's not uncommon for various automation processes to refer to CPC by
name. Again, allow for this. 
-- Many folks in the IT community may be attached to the old name in various
ways. Any change must 'socialized' thoroughly. 

I suggest you pick a name that you won't regret later. Consider the effects
of future model upgrades, workload repurposing, and physical relocation.
However, if an upgrade involves a transition period where both old and new
boxes must coexist, you need two separate names at least for a while. I can
see the appeal of serial number to avoid these conundrums, buy as you note
the number is meaningless to all but a handful of infrastructure geeks. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net
jo.skip.robin...@gmail.com


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Elardus Engelbrecht
> Sent: Thursday, January 7, 2016 04:56 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Change CPC name in HMC
> 
> Tony Thigpen wrote:
> 
> >I have done such a change on two z10s with good results. The third time 
did
> not go so well. For some reason, the secondary cpc did not change. 
Everything
> looked ok until we did a POR, then it would not come up. We had to 
restore the
> CPC.
> 
> Ouch. Where is that behaviour documented?
> 
> Do you get a warning during the renaming that an upcoming POR may fail?
> 
> >I don't know what went wrong, but after that, we no longer change the
> names.
> 
> Now you got a new scar and a T-shirt as a bonus ... :)
> 
> I would also not repeat that stunt after one failure.
> 
> 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



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

--
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: SMFxTME field

[Barry Merrill]

It's actually the SMFSTAMP8. format provided in the SAS language that converts
the datetime format into a SAS datetime variable, which contains the number of
seconds plus/minus Jan 1, 1960, the IBM epoch.  (Unix and other use 1970).

There are 670 instances of variables INPUT with the SMFSTAMP8 informat in the 
MXG source library, and 1538 instances of variables INPUT with TODSTAMP8 
informat.

SMFSTAMP is limited to 2 decimal resolution (10 milliseconds) while most 
TODSTAMP8
fields have microsecond resolution.

One of the beauties of SAS datetime variables is the ability to under specify 
the
length of the datetime FORMAT (DATETIME21.2 for SMFSTAMP, DATETIME25.6 for 
TODSTAMP)
so that FORMAT VARIABLE DATE9. ; can be used to summarize/report by DATE 
(06JAN2016)
without creating a DATE variable, or FORMAT VARIABLE DATETIME12.; can be used to
report/summarize by DATE and HOUR (06JAN2016:12) and FORMAT VARIABLE 
DATETIME13. can be used
report/summarize by DATE/HOUR/and MINUTE (06JAN2016:12:30) without creating new 
variables.


MERRILLY NEW YEAR,

Barry


Herbert W. “Barry” Merrill, PhD
President-Programmer
MXG Software
Merrill Consultants
10717 Cromwell Drive
Dallas, TX 75229-5112
ba...@mxg.com
Fax:  214 350 3694 – Still works, received as email
Tel:  214 351 1966 – Unreliable, please use email

www.mxg.comHomePage: FAQ answers most questions
ad...@mxg.com  License Forms, Invoice, Payment, ftp information
supp...@mxg.comTechnical Issues 
MXG-L FREE ListServer  http://www.mxg.com/mxg-l_listserver/



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Neil Duffee
Sent: Wednesday, January 06, 2016 2:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMFxTME field

Caveat:  with daily digesting, I'm at least a day behind the discussion...

Actually, I believe that MXG is SMFxxDTE & SMFxxTME cognizant by virtue of 
using the underlying SAS 'inFormat's SMFDATETIME, SMFDATE, & SMFTIME.  I do my 
SMF reporting using SAS directly and, using SMFDATETIME, get SAS Date/DateTime 
variables [1] that can have the (out) 'Format's you desire.  

[1]  If I remember rightly, the SAS internal representations are #seconds or 
days from an arbitrary point ie.  Jan 01, 1970 (or 1900?).  That means, 
internally, the raw value can be negative for dates/times in previous 
(Gregorian) centuries, etc.

>  signature = 8 lines follows  <
Neil Duffee, Joe Sysprog, uOttawa, Ottawa, Ont, Canada
telephone:1 613 562 5800 x4585  fax:1 613 562 5161
mailto:NDuffee of uOttawa.ca http:/ /aix1.uOttawa.ca/ ~nduffee
“How *do* you plan for something like that?”  Guardian Bob, Reboot “For every 
action, there is an equal and opposite criticism.”
“Systems Programming: Guilty, until proven innocent”  John Norgauer 2004 
"Schrodinger's backup: The condition of any backup is unknown until a restore 
is attempted."  John McKown 2015

-Original Message-
From: Charles Mills [mailto:cha...@mcn...org]
Sent: January 5, 2016 19:46
Subject: Re: SMFxTME field

Of course, if you have the good Doctor Merrill's most excellent MXG software 
then it will do all of this for you and more in but a trice!

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Tuesday, January 05, 2016 4:30 PM
Subject: Re: SMFxTME field

The SMFxxTME and SMFxxDTE fields are in my experience consistent 
representations of *local* time and date on the LPAR represented by the SMFID. 
No worries about leap seconds (unless you need to get back to some more basic 
time than local).


--
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: SRB And Enclave SRB

[Barry Merrill]

Look at the value of SMF30SNF or SMF70NRM, divide it by 256,
and that is the speedup ratio of your zIIP engine compared 
with the CP engine speed, and I've seen higher ratios than 4.

Barry


Herbert W. "Barry" Merrill, PhD
President-Programmer
MXG Software
Merrill Consultants
10717 Cromwell Drive
Dallas, TX 75229-5112
ba...@mxg.com
Fax:  214 350 3694 - Still works, received as email
Tel:  214 351 1966 - Unreliable, please use email

www.mxg.comHomePage: FAQ answers most questions
ad...@mxg.com  License Forms, Invoice, Payment, ftp information
supp...@mxg.comTechnical Issues 
MXG-L FREE ListServer  http://www.mxg.com/mxg-l_listserver/



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Klein, Kenneth E
Sent: Tuesday, December 22, 2015 2:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SRB And Enclave SRB

We just enabled zPSaver Suite on an LPAR on a z12 z/os 2.1 as a POC. We're
getting 72.1 percent offloaded to zIIP on that LPAR. There's a little
savings in IEBGENER, too, but too little to matter.

What I can't figure out is where the CPU time went, because I did NOT see
the 72.1 percent show up in the zIIP column. I know the specialty engines
are not hamstrung like the 2827-H43-407 general purpose engines, but it
looks the 1 zIIP on the CEC is 4 times faster! Can that be true? Any form of
reality check would be welcome here.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Blaicher, Christopher Y.
Sent: Friday, November 06, 2015 10:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SRB And Enclave SRB

Go to http://www.syncsort.com/en/Products/Mainframe/ZPSaverSuite and see
what we can do on z/IIP engines.  In a nutshell, we can offload about 90% of
our normal TCB workload to a z/IIP engine, your mileage may vary depending
on a number of things, but we can do an awful lot.  This has been a
multi-year project by a number of very talented people.

Chris Blaicher
Technical Architect
Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Clark Morris
Sent: Friday, November 06, 2015 11:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SRB And Enclave SRB

On 6 Nov 2015 08:11:52 -0800, in bit.listserv.ibm-main you wrote:

>SRB's were not meant for general application code.  Also, I hope nobody
builds a quick and dirty SRB routine.  Those should be carefully constructed
and tested.
>If by quick and dirty you mean short lived, then yes, that was their
original use case.  Some SRB routines today are much more robust and can do
significant work, but that is what the z/IIP engines are for.

What is the work done on a Ziip engine?  As I understand other postings
(possibly incorrectly) the work runs under an enclave SRB.
Java and XML parsing to my mind are application code.  I can't speak as to
what type of code DF/Sort and Syncsort are running on Ziip and Zaap.

Clark Morris
>
>
>Chris Blaicher
>Technical Architect
>Software Development
>Syncsort Incorporated
>50 Tice Boulevard, Woodcliff Lake, NJ 07677
>P: 201-930-8234  |  M: 512-627-3803
>E: cblaic...@syncsort.com
>





ATTENTION: -

The information contained in this message (including any files transmitted
with this message) may contain proprietary, trade secret or other
confidential and/or legally privileged information. Any pricing information
contained in this message or in any files transmitted with this message is
always confidential and cannot be shared with any third parties without
prior written approval from Syncsort. This message is intended to be read
only by the individual or entity to whom it is addressed or by their
designee. If the reader of this message is not the intended recipient, you
are on notice that any use, disclosure, copying or distribution of this
message, in any form, is strictly prohibited. If you have received this
message in error, please immediately notify the sender and/or Syncsort and
destroy all copies of this message in your possession, custody or control.

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

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

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

Re: OT: Electrician cuts wrong wire and downs 25,000 square foot data centre

[Barry Merrill]

When the IBM 7094 at Purdue University was finally to be disconnected,
they had to shut down the entire power plant, which was adjacent
to the computer building, because the computer's main power relay 
had been directly connected to the main power buss, and it's contacts
had welded shut over those many years.

SW Bell was about to open a brand new office building in downtown Dallas
with hundreds ready to move in the next week; the only remaining work
was to lay the carpet, and that team diligently laid and cut the
carpet flush to the perimeter, failing to observe that under the
carpet were miles of multi-conductor flat cables to all of the 
devices that were also cut along with the carpet.  I believe it
took a LONG time to replace/rerun all of those cables.

Barry


Herbert W. “Barry” Merrill, PhD
President-Programmer
MXG Software
Merrill Consultants
10717 Cromwell Drive
Dallas, TX 75229-5112
ba...@mxg.com
Fax:  214 350 3694 – Still works, received as email
Tel:  214 351 1966 – Unreliable, please use email

www.mxg.comHomePage: FAQ answers most questions
ad...@mxg.com  License Forms, Invoice, Payment, ftp information
supp...@mxg.comTechnical Issues 
MXG-L FREE ListServer  http://www.mxg.com/mxg-l_listserver/



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Monday, December 14, 2015 10:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: OT: Electrician cuts wrong wire and downs 25,000 square foot data 
centre

And since we're talking electricity this reminded me of the time a large possum 
decided to crawl into some electrical boxes and die for some reason (this was 
well inside the building).  The body was discovered after a while by odor, and 
people thought he could not be removed safely without cutting off power to 
about half the datacenter.  I remember managers asking us what was connected to 
what so they would have an idea of what servers would go down, but I can't 
remember if they eventually removed him by shutting down power or by just being 
very careful.  The big guy was laying right above some 3-phase copper cables 
that were each about an inch in diameter - possibly the lines coming directly 
from the power company.

Mullen, Patrick wrote:
> Since we're recalling ancient history stuff...In the 80s I was at a site that 
> replaced a small HDS box (approx 4341 equivalent) with a much large one 
> (approx 3081 equivalent). The UPS itself was big enough so they just plugged 
> in the same cables. Problem is nobody had rethought the cables, first time we 
> flipped over to test running on UPS the new box drew so much more juice that 
> the cables actually melted. Yes it was a government site (Elardus would know 
> them), and yes the electrical work was done by a lowest bid contractor.
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Ken Hume
> Sent: Monday, December 14, 2015 10:08 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: OT: Electrician cuts wrong wire and downs 25,000 square 
> foot data centre
> 
> I remember an incident when I was in Atlanta.
> 
> We had a new, actually our first, UPS installed. Everything was completed and 
> hooked up.
> 
> The electricians decided to test it in the MIDDLE of the WEEK DAY and WITHOUT 
> telling anyone.
> 
> Guess what happened Yep. Entire data center was down for almost 4 
> hours.
> 
> Ken
> 
> On 12/13/2015 10:27 PM, Brian Westerman wrote:
> 
>>In 2012 I was at a data center in Colorado where we were upgrading 
>>them from OS/390 2.10 to z/OS 1.13 and simultaneously replacing their 
>>9672 with a z/114.  We had just completed the "2 weeks in production" 
>>period for the z/114 and was going so well that the site decided to 
>>have the 9672 removed early (we were scheduled for 1 month of hot 
>>backup).  The 9672 still had some old power cables snaked around under 
>>the raised flooring and I guess they were stuck around some REALLY old 
>>Buss and tag (from their 4381 they had in the late 80's) cables and 
>>raised floor stands.  We offered to help the guy unwrap them, but he 
>>told us that we were not "certified electricians" and that the union 
>>would crucify him if he allowed us to touch anything.  The electrician 
>>then apparently decided that since he had disconnected the power 
>>cables from the wall and the CPU that he could just "give them a good 
>>yank".  We were discussing things with the client in their operations 
>>area, when we felt a s
ort of "vibration" and the consoles locked up.  It turned out that the 
electrician had yanked the floor supports completely from the safety stands and 
the 9672 fell about 2 feet to the cement.
&g

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Barry Merrill]

At Purdue University, in 1965, the Share Programming Library (might not be
quite
right name) card decks filled cabinets that were 6 feet tall and about 40
feet
of wall space.  These were the contributed programs and subroutines
available to
all SHARE members.  I can't recall if they were automatically send or had to
be
requested, but I think all possible card decks were in those cabinets.

Barry


Herbert W. "Barry" Merrill, PhD
President-Programmer
MXG Software
Merrill Consultants
10717 Cromwell Drive
Dallas, TX 75229-5112
ba...@mxg.com
Fax:  214 350 3694 - Still works, received as email
Tel:  214 351 1966 - Unreliable, please use email

www.mxg.comHomePage: FAQ answers most questions
ad...@mxg.com  License Forms, Invoice, Payment, ftp information
supp...@mxg.comTechnical Issues 
MXG-L FREE ListServer  http://www.mxg.com/mxg-l_listserver/



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Joel C. Ewing
Sent: Thursday, December 03, 2015 10:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What's a "ton" of JCL? [was:RE: Straightforward way to
determine hardware architecture level?]

On 12/02/2015 11:09 PM, Ed Gould wrote:
> On Dec 2, 2015, at 2:58 PM, Joel C. Ewing wrote:
>
>> I just weighed the one almost-full box of some old programs and data 
>> cards that I have retained for show-and-tell over the years, and it 
>> is a little over 8 lbs.  Since the cards have holes punched, have 
>> some lighter cardboard spacers, and new cards pack more tightly, I 
>> would estimate 10 lbs as a better approximation for a box of 2000 
>> unused cards.
>>
>> Before we started conversion from DOS/VSE to MVS in 1985, all our 
>> production JCL was on cards in several card filing cabinets.  My 
>> recollection is that a cabinet drawer could hold around two boxes of 
>> cards, so the maximum capacity of one cabinet might have been on the 
>> order of 40 boxes of cards.  We could easily have had somewhere in 
>> the neighborhood of 0.5 - 1.0 tons of cards containing JCL.  A larger 
>> shop might literally have had several tons of JCL.
>> Joel C. Ewing
>
>
> Joel:
> Interesting. I have never worked in a shop (last say 45 years) where 
> there was that much punched cards. There were some cases where the 
> programmer submitted boxes of cards for one time update to a source 
> lib and maybe 5 or so JCL cards. Production was similar one or two job 
> cards a joblib and exec and then probably either a /* or // card.
>
> None of the shops I have ever worked in used that much JCL PERIOD.
>
> This does not include a very few jobs that had "data" cards mind you.
> Those types of jobs were rare and were handled as a card to tape on 
> the dos side and used a tape on the MFT/MVT side.
>
> Ed
>
>
When I came on-board in 1978,  all program development and maintenance and
test job submission, except for one or two Luddite-programmer holdouts who
still edited source decks,  was done from IBM 3277's using a home-grown
On-Line Editor (OLE') system running under a home-grown multi-tasking
("Mini-Task") interactive environment, which supported multiple interactive
on-line applications in a single DOS/VS job partition.  Because DOS/VS had
native support for source and object libraries, those were kept online, but
there was no decent native support to effectively submit production job JCL
from libraries and the company was averse to spending on "unneeded"
additional software, so production JCL was created in OLE' but punched and
kept on cards for use by Operations. 

At one time the company had been a service bureau.  That was no longer the
case when I arrived -- by then it was just the DP subsidiary of Arkansas
Best Corp -- but they continued to support and do processing for former
service-bureau customers who chose to stay.  That meant, for example, that
there might be many different payroll, accounts payable, accounts
receivable, etc.  JCL job decks executing essentially the same programs but
with different parameters and files.  So our ratio of JCL images to program
source images might have been higher than typical.

When we started DOS/VSE to MVS/XA migration in 1985, we were already running
the maximum of four, shared-SPOOL DOS/VSE systems under VM and all on-line
applications had by then been converted to run under CICS. 
We converted to VM/XA  (I think still called "VM Migration Aid" at the
time) to also support MVS/XA.  As primary technical support for MVS, the
very  first "production" application I created under MVS was to set up a
TSO/ISPF application to allow operators to submit DOS production JCL from an
efficiently-blocked MVS PDS library under MVS using an MVS VM virtual card
punch feeding a DOS VM virtual card reader.  Not only d

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[Barry Merrill]

I think a box of 2000 IBM cards is on the order of 6 pounds,
so a TON of JCL cards would be 333 boxes, or about 666,666
card images.

But, the useful weight is zero, since we only use the holes.

Barry


Herbert W. "Barry" Merrill, PhD
President-Programmer
MXG Software
Merrill Consultants
10717 Cromwell Drive
Dallas, TX 75229-5112
ba...@mxg.com
Fax:  214 350 3694 - Still works, received as email
Tel:  214 351 1966 - Unreliable, please use email

www.mxg.comHomePage: FAQ answers most questions
ad...@mxg.com  License Forms, Invoice, Payment, ftp information
supp...@mxg.comTechnical Issues 
MXG-L FREE ListServer  http://www.mxg.com/mxg-l_listserver/



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Farley, Peter x23353
Sent: Tuesday, December 01, 2015 1:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: What's a "ton" of JCL? [was:RE: Straightforward way to determine
hardware architecture level?]

Re: "ton" of JCL, at least one large shop of my prior acquaintance (20 or so
years ago) had over 250,000 members in the production applications JCL
libraries.

Not sure how much of that was obsolete at the time, but the batch operations
control product they used had vast quantities of data as well.

I think that counts as a "ton" or 2 . . . :)

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Tuesday, December 01, 2015 9:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture level?



. . . migrating from Cobol 4 to Cobol 5 without changing a ton of JCL (how
much JCL is a "ton" anyway?).

--

This message and any attachments are intended only for the use of the
addressee and may contain information that is privileged and confidential.
If the reader of the message is not the intended recipient or an authorized
representative of the intended recipient, you are hereby notified that any
dissemination of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by e-mail
and delete the message and any attachments from your system.

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

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

Re: IPL wait state

[Barry Merrill]

Precisely what occurred.

The story is in ACHAP34 in the MXG Source Library, added well after the 
incident.

As all three had been sent to SHARE by management, there was NO DESIRE to 
publicize
at the time of the incident.

Barry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pommier, Rex
Sent: Thursday, November 12, 2015 2:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL wait state

Elardus,

IIRC, the incident was pre-RACF, and the system datasets were protected with 
passwords on the datasets themselves and somebody forgot to put a password on 
SYS1.NUCLEUS.  

Rex


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Thursday, November 12, 2015 1:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL wait state

Barry Merrill wrote:

>... The challenge was accepted, and in short order, "Tim W." observed that 
>SYS1.NUCLEUS was not protected, so he scratched it.  "Tim W." knew that once 
>the system is up, the dataset SYS1.NUCLEUS is not read again, so the SHARE 
>demonstration continued without flaw.  It was later heard that IBM took the 
>SHARE MVS demonstration down at 11 p.m. to IPL for a customer benchmark; it 
>took until 3 a.m. for IBM to find a CE who could correctly decipher the wait 
>state code and explain that the IPLs kept failing because there was no 
>SYS1.NUCLEUS on the IPL volume.

Wow! Barry! That is one of the best war stories I read on IBM-MAIN! I really 
enjoyed your story, especially that big blue have a hard time to fix things! 

Now, DASD were probably not shared, how did that CE found out what the real 
problem was? Dumps? Inspecting Consoles/SYSLOG printouts? SAD?

Ok, was there really any 'security'? I believe RACF was at its infancy at that 
time! ;-)

Barry, do you have any documentation or link of this fun story? 

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

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

Re: IPL wait state

[Barry Merrill]

At the Chicago SHARE 43 meeting in August, 1974, IBM had invited
attendees to a demonstration of the new MVS operating system on the 145
at the Chicago Ed center.  At 8 p.m. Tuesday, three attendees found the
IBM demonstrator on duty was enthralling an attractive lady with his
expertise.  Not wanting to be interrupted by three males, he said, "Go
play with the system on that user TSO terminal over there -- you can
find out how good the security of an MVS system is for a typical TSO
user”.  The challenge was accepted, and in short order, "Tim W." observed
that SYS1.NUCLEUS was not protected, so he scratched it.  "Tim W." knew
that once the system is up, the dataset SYS1.NUCLEUS is not read again,
so the SHARE demonstration continued without flaw.  It was later heard
that IBM took the SHARE MVS demonstration down at 11 p.m. to IPL for a
customer benchmark; it took until 3 a.m. for IBM to find a CE who could
correctly decipher the wait state code and explain that the IPLs kept
failing because there was no SYS1.NUCLEUS on the IPL volume.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Thursday, November 12, 2015 9:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL wait state

On 12 November 2015 at 05:09, Nathan Astle  wrote:
> i got the below message in the HMC,
>
> Central processor (CP) 0 is looping due to switching between program 
> status words (PSWs) that are not valid. The program status word (PSW) 
> is .
>
> The IPLTEXT was not written to the newly cloned RES Volume. Could that 
> be a reason ?

Yes. But there are many other possible causes; anything that overlays the 
program new PSW in low storage can provoke it. If another processor is 
available to z/OS it should be able to stop the loop, but not always.

> I am not getting a correct explanation about x'000' on my search about 
> the above PSW in MVS manual codes.

If it's not a wait-state PSW, there will be no wait state code present. More 
exactly, if it's not a disabled wait-state PSW, there is no wait state code 
documented in the MVS System Codes because this is not an error situation; it's 
just the system with no work to do. In this case of an enabled wait, the PSW 
address will usually be 0, though there is no architectural reason it couldn't 
be anything at all that the system wants to leave there..

In this case almost certainly the system is in that strange condition described 
in the Principles of Operation where the program new PSW is invalid (and 
subject to early detection). When this PSW is loaded as the result of a program 
interrupt, another (specification) program interrupt immediately becomes 
pending. This interrupt has a higher priority than almost anything else, and so 
hitting STOP or even RESTART will not stop the loop.

I imagine that on modern machines the HMC warns when this situation occurs, 
just as VM has for decades.

Tony H.

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

FW: Alias usage is reported in SMF14ALIAS added in z/OS 2.2

[Barry Merrill]

Nothing like forgetting to read your own recent changes.

The Alias Name, SMF14ALIAS, was added to the SMF 14/15 records in z/OS 2.2.

I typo'ed the name in the KEEP list in MXG as SMR14ALIAS (now corrected)
which caused the variable to be not kept and hence missed when I re-checked
for SMF and ALIAS before posting my incorrect earlier posting.


Merrilly yours,
Barry


Herbert W. "Barry" Merrill, PhD
President-Programmer
MXG Software
Merrill Consultants
10717 Cromwell Drive
Dallas, TX 75229-5112
ba...@mxg.com
Fax:  214 350 3694 - Still works, received as email
Tel:  214 351 1966 - Unreliable, please use email

www.mxg.comHomePage: FAQ answers most questions
ad...@mxg.com  License Forms, Invoice, Payment, ftp information
supp...@mxg.comTechnical Issues 
MXG-L FREE ListServer  http://www.mxg.com/mxg-l_listserver/



-Original Message-----
From: Barry Merrill [mailto:ba...@mxg.com] 
Sent: Tuesday, November 10, 2015 8:06 AM
To: 'IBM Mainframe Discussion List' <IBM-MAIN@LISTSERV.UA.EDU>
Subject: RE: Alias usage

The only appearance in SMF of the Alias name is in the SMF 42 subtypes 21
and 24 for delete member alias and delete alias events.

Barry


Herbert W. "Barry" Merrill, PhD
President-Programmer
MXG Software
Merrill Consultants
10717 Cromwell Drive
Dallas, TX 75229-5112
ba...@mxg.com
Fax:  214 350 3694 - Still works, received as email
Tel:  214 351 1966 - Unreliable, please use email

www.mxg.comHomePage: FAQ answers most questions
ad...@mxg.com  License Forms, Invoice, Payment, ftp information
supp...@mxg.comTechnical Issues 
MXG-L FREE ListServer  http://www.mxg.com/mxg-l_listserver/




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Styles, Andy (SD EP zPlatform)
Sent: Tuesday, November 10, 2015 7:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Alias usage

Hi all, 

Does anyone know of a way to track usage of dataset alias usage? 

We have quite a number of datasets with that have historic aliases which
could do with tidying up - but I don't want to remove any aliases until I'm
comfortable that I'm not going to break anything that has them coded (for
example) in JCL. 

I've looked at SMF, and it only appears to record the real dataset name, not
the alias.

Any ideas?

Thanks,

--
Andy Styles 


Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ.
Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank
plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in
England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc.
Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no.
SC327000. Telephone: 03457 801 801. Cheltenham & Gloucester plc. Registered
Office: Barnett Way, Gloucester GL4 3RL. Registered in England and Wales
2299428. Telephone: 0345 603 1637

Lloyds Bank plc, Bank of Scotland plc are authorised by the Prudential
Regulation Authority and regulated by the Financial Conduct Authority and
Prudential Regulation Authority.

Cheltenham & Gloucester plc is authorised and regulated by the Financial
Conduct Authority.

Halifax is a division of Bank of Scotland plc. Cheltenham & Gloucester
Savings is a division of Lloyds Bank plc.

HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in
Scotland no. SC218813.

This e-mail (including any attachments) is private and confidential and may
contain privileged material. If you have received this e-mail in error,
please notify the sender and delete it (including any attachments)
immediately. You must not copy, distribute, disclose or use any of the
information in it or any attachments. Telephone calls may be monitored or
recorded.

--
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: Alias usage

[Barry Merrill]

The only appearance in SMF of the Alias name is in the SMF 42 subtypes 21
and 24 for 
delete member alias and delete alias events.

Barry


Herbert W. "Barry" Merrill, PhD
President-Programmer
MXG Software
Merrill Consultants
10717 Cromwell Drive
Dallas, TX 75229-5112
ba...@mxg.com
Fax:  214 350 3694 - Still works, received as email
Tel:  214 351 1966 - Unreliable, please use email

www.mxg.comHomePage: FAQ answers most questions
ad...@mxg.com  License Forms, Invoice, Payment, ftp information
supp...@mxg.comTechnical Issues 
MXG-L FREE ListServer  http://www.mxg.com/mxg-l_listserver/




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Styles, Andy (SD EP zPlatform)
Sent: Tuesday, November 10, 2015 7:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Alias usage

Hi all, 

Does anyone know of a way to track usage of dataset alias usage? 

We have quite a number of datasets with that have historic aliases which
could do with tidying up - but I don't want to remove any aliases until I'm
comfortable that I'm not going to break anything that has them coded (for
example) in JCL. 

I've looked at SMF, and it only appears to record the real dataset name, not
the alias.

Any ideas?

Thanks,

-- 
Andy Styles 


Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ.
Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank
plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in
England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc.
Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no.
SC327000. Telephone: 03457 801 801. Cheltenham & Gloucester plc. Registered
Office: Barnett Way, Gloucester GL4 3RL. Registered in England and Wales
2299428. Telephone: 0345 603 1637

Lloyds Bank plc, Bank of Scotland plc are authorised by the Prudential
Regulation Authority and regulated by the Financial Conduct Authority and
Prudential Regulation Authority.

Cheltenham & Gloucester plc is authorised and regulated by the Financial
Conduct Authority.

Halifax is a division of Bank of Scotland plc. Cheltenham & Gloucester
Savings is a division of Lloyds Bank plc.

HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in
Scotland no. SC218813.

This e-mail (including any attachments) is private and confidential and may
contain privileged material. If you have received this e-mail in error,
please notify the sender and delete it (including any attachments)
immediately. You must not copy, distribute, disclose or use any of the
information in it or any attachments. Telephone calls may be monitored or
recorded.

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