Re: How to use LISTDSI from Rexx under Unix shell?

[Paul Gilmartin]

On Sun, 9 Oct 2022 21:07:57 +, Farley, Peter x23353  wrote:
>>>
>>If it doesn't work it deserves an SR.  Can you Edit/View files so tagged with 
>>ISPF?
>
>IIRC I have to use the 3.17 Unix directory browser and a "/" to execute "View 
>ASCII/UTF8" or "Edit ASCII/UTF8", as I am unfamiliar with the 3.17 line 
>commands to do that (VA or EA maybe?  I really need to go look those up and 
>start using them), but yes, I CAN view or edit them when so tagged.
> 
In my experience, a file tagged 819 or 1208 and FILEDATA is recognized and 
processid
by ISPF; I needn't specify EA or VA.

>>>I originally did not think of using LRECL/RECFM overrides on the SYSEXEC 
>>>allocation because I thought they would be incompatible with the PATH 
>>>keywords.  
>>>
>>I'd say you underestimate IBM, but I've had too much unpleasant experience 
>>overestimating IBM in such matters.  BTW, DCB=(LRECL,...) is incompatible 
>>with PATH.  WHY!?
>
>Good question, but probably not one to which we can get a straight answer.  At 
>a guess, old and crotchety JCL interpretation code that no one wants to touch 
>(if it ain't broke, don't fix it), while the "outside a DCB" keywords are 
>probably in newer OCO code that is "easier" (FSVO "easier") to maintain.
> 
I suspect the JCL Converter has no ability to detect a conflict between one 
option and
a suboption of another option.

>>> IBM could provide better and more complete examples of accessing Unix 
>>> files from a TSO or batch task
>+1...
>N t just HLASM SYSLIB, but also Binder SYSLIB and any/all HLL compiler 
>SYSLIB's, STEPLIB/JOBLIB, et alia: Basically, anywhere a Unix directory can 
>validly be used as a library.  Such usage probably warrants a sub-chapter of 
>its own, or at least a page or two somewhere prominent.
> 
I believe Binder is exceptional.  It (necessarily) supported UNIX files in an 
intervel when
Allocation supported PATH but access methods didn't.  In consequence:

o Binder does not support non-trivial concatenations containing UNIX PATHs.

o Binder ignores FILEDATA and
  - treats SYSLIN as BINARY
  - treats SYSPRINT as TEXT.

I consider it indolent design that Binder does not issue a Warning if the 
programmer
codes a conflicting FILEDATA.  I've whined about that here and an IBM 
representative
(Peter?) has said that if I supply invalid input I should not expect any 
specific
behavior such as a message.  That's below the product quality I expect of IBM.

o Binder does not use BPAM, I believe in part because BLDL can't deal with
  UNIX filenames.

>Suggested (sub)chapter title: "Using Unix Directories as libraries".  JCL 
>Programmer's Guide perhaps, with sufficient examples to cover all the bases 
>for both TSO and batch execution.
>
>Actually, I don’t think I've even looked at the JCL Programmer's Guide in too 
>many years, so maybe I should go see what's there these days.
>
>>>   ... that show which DD keywords are compatible with Unix allocations, but 
>>> I won't hold my breath waiting for such to be created.  There may be some 
>>> table(s) somewhere (maybe in the JCL reference manual?) that show 
>>> compatibility, but it's my fault that I haven't looked for them yet.
>>> 
>>There used to be such a matrix, in the JCL Ref., IIRC.  Perhaps it outgrew 
>>page size and IBM 
>>simply dropped it in favor of scattered "Relationship to other parameters" 
>>sentences.

-- 
gil

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

Re: 50 Years of SAS

[Doug]

Barry,
That is a great bit of history that I am sure many will and are enjoying .
Bravo Sir and congratulations to a long and prosperous journey!
Warm Regards, Doug 

.

On Oct 9, 2022, at 18:46, Jerome Benting  wrote:

Bravo SIR .. Used SAS & MXG extensively in my SysProg days.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Barry Merrill
Sent: Sunday, October 9, 2022 6:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 50 Years of SAS

 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 

Re: 50 Years of SAS

[Jerome Benting]

Bravo SIR .. Used SAS & MXG extensively in my SysProg days.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Barry Merrill
Sent: Sunday, October 9, 2022 6:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 50 Years of SAS

  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 

Re: How to use LISTDSI from Rexx under Unix shell?

[Farley, Peter x23353]

On Sunday, October 9, 2022 3:52 PM, Paul Gilmartin wrote:

>On Sun, 9 Oct 2022 19:00:26 +, Farley, Peter x23353 wrote:
>

>
>> ... At the time of that ISO8859-1 test I know I did NOT have the LRECL/RECFM 
>> override in place for the SYSEXEC allocation, so that may have been the 
>> problem rather than the file encoding.
>>
>If it doesn't work it deserves an SR.  Can you Edit/View files so tagged with 
>ISPF?

IIRC I have to use the 3.17 Unix directory browser and a "/" to execute "View 
ASCII/UTF8" or "Edit ASCII/UTF8", as I am unfamiliar with the 3.17 line 
commands to do that (VA or EA maybe?  I really need to go look those up and 
start using them), but yes, I CAN view or edit them when so tagged.

>>I originally did not think of using LRECL/RECFM overrides on the SYSEXEC 
>>allocation because I thought they would be incompatible with the PATH 
>>keywords.  
>>
>I'd say you underestimate IBM, but I've had too much unpleasant experience 
>overestimating IBM in such matters.  BTW, DCB=(LRECL,...) is incompatible with 
>PATH.  WHY!?

Good question, but probably not one to which we can get a straight answer.  At 
a guess, old and crotchety JCL interpretation code that no one wants to touch 
(if it ain't broke, don't fix it), while the "outside a DCB" keywords are 
probably in newer OCO code that is "easier" (FSVO "easier") to maintain.

>> IBM could provide better and more complete examples of accessing Unix 
>> files from a TSO or batch task
>+1
>At least complete examples for IEBGENER SYSUT1 and HLASM SYSLIB, both showing 
>examples of mixed concatenation.  The best I find easily is in Using Data Sets:
>//SYSUT2  DD PATH='/sj/sjpl/xsam/xpm17u01/paytime',
>//   PATHDISP=(KEEP,DELETE),
>//   PATHOPTS=(OCREAT,ORDWR),
>//   PATHMODE=(SIRUSR,SIWUSR,
>// SIRGRP,SIROTH),
>//   FILEDATA=TEXT

+1
Not just HLASM SYSLIB, but also Binder SYSLIB and any/all HLL compiler 
SYSLIB's, STEPLIB/JOBLIB, et alia: Basically, anywhere a Unix directory can 
validly be used as a library.  Such usage probably warrants a sub-chapter of 
its own, or at least a page or two somewhere prominent.

Suggested (sub)chapter title: "Using Unix Directories as libraries".  JCL 
Programmer's Guide perhaps, with sufficient examples to cover all the bases for 
both TSO and batch execution.

Actually, I don’t think I've even looked at the JCL Programmer's Guide in too 
many years, so maybe I should go see what's there these days.

>>   ... that show which DD keywords are compatible with Unix allocations, but 
>> I won't hold my breath waiting for such to be created.  There may be some 
>> table(s) somewhere (maybe in the JCL reference manual?) that show 
>> compatibility, but it's my fault that I haven't looked for them yet.
>> 
>There used to be such a matrix, in the JCL Ref., IIRC.  Perhaps it outgrew 
>page size and IBM simply dropped it in favor of scattered "Relationship to 
>other parameters"
>sentences.
--

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

Open Job Positions? - ZOS / Performance / Tuning

[Steve Estle]

Hello Everyone,

I know this is primarily a "technical discussion" set of forums.  But wanted to 
post this anyways.  Little of my background - I worked at IBM 34+ years in a 
number of positions, but my predominant area of expertise was in MVS (SP, XA, 
ESA), OS390, etc. working in systems programming arena.  I also am highly 
skilled in performance and tuning with deep experience with tuning (RMF, SAS, 
Omegamon, and others).   I was the team lead for the MVS performance team in 
Boulder, CO for several years and got certified in this discipline. I performed 
these activities for ~20 years, but my skills are a bit rusty / out of date as 
I then moved into more leadership roles latter part of my career but know I can 
catch up relatively quickly and have been perusing docs, etc to do just that.  
I also have experience with VM as well - but not as extensive as my MVS years.  
My whole IBM career was spent in internal IS, Consulting, and outsourcing arena 
- so was in services role for 34+ years.

Anyways I'm back looking for potential job positions if anyone is looking or 
knows of available positions - happy to share resume if anyone would like to 
talk further - my email is sest...@gmail.com.

Thanks all in advance,

Steve Estle

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

Re: How to use LISTDSI from Rexx under Unix shell?

[Paul Gilmartin]

On Sun, 9 Oct 2022 19:00:26 +, Farley, Peter x23353 wrote:

>I believe I tried just removing the DSNTYPE(HFS) and it failed, but I will try 
>that again at my next opportunity to see what happens.
>
The two uses of DSNTYPE I can find are

Identify the file type as either PIPE (a FIFO file) that is coded in 
combination
with the PATH operand or

as an HFS (hierarchical file system) specified in combination with the 
DSNAME operand.
HFS indicates that the data set is an HFS data set which contains a z/OS® 
UNIX
hierarchical file system.

( I believe the latter is obsolete and not what you intend.  You didn't specify 
DSN.)

DSNTYPE does support other values (for example LIBRARY, PDS, EXTREQ,
EXTPREF, LARGE, and BASIC), but these are not appropriate for HFS files.

>Yes, my Rexx programs are tagged (IBM1047 and text), and yes, the 
>auto-conversion incantations are active.  I thought I tried tagging as 
>ISO8859-1 and text and it failed to execute a called Rexx program in the Unix 
>directory with a WRONG.LENGTH.RECORD error,
>
I'm too familiar with that for LRECL too small.  It should have a different M 
because
RECORD historically meant "block" when that message was issued.

> ... but I will repeat that test to verify.  At the time of that ISO8859-1 
> test I know I did NOT have the LRECL/RECFM override in place for the SYSEXEC 
> allocation, so that may have been the problem rather than the file encoding.
>
If it doesn't work it deserves an SR.  Can you Edit/View files so tagged with 
ISPF?

>I originally did not think of using LRECL/RECFM overrides on the SYSEXEC 
>allocation because I thought they would be incompatible with the PATH 
>keywords.  
>
I'd say you underestimate IBM, but I've had too much unpleasant experience 
overestimating
IBM in such matters.  BTW, DCB=(LRECL,...) is incompatible with PATH.  WHY!?

> IBM could provide better and more complete examples of accessing Unix files 
> from a TSO or batch task
>
+1
At least complete examples for IEBGENER SYSUT1 and HLASM SYSLIB, both showing 
examples
of mixed concatenation.  The best I find easily is in Using Data Sets:
//SYSUT2  DD PATH='/sj/sjpl/xsam/xpm17u01/paytime',
//   PATHDISP=(KEEP,DELETE),
//   PATHOPTS=(OCREAT,ORDWR),
//   PATHMODE=(SIRUSR,SIWUSR,
// SIRGRP,SIROTH),
//   FILEDATA=TEXT

>   ... that show which DD keywords are compatible with Unix allocations, but I 
> won't hold my breath waiting for such to be created.  There may be some 
> table(s) somewhere (maybe in the JCL reference manual?) that show 
> compatibility, but it's my fault that I haven't looked for them yet.
> 
There used to be such a matrix, in the JCL Ref., IIRC.  Perhaps it outgrew page 
size
and IBM simply dropped it in favor of scattered "Relationship to other 
parameters"
sentences.

-- 
gil

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

Re: How to use LISTDSI from Rexx under Unix shell?

[Farley, Peter x23353]

I believe I tried just removing the DSNTYPE(HFS) and it failed, but I will try 
that again at my next opportunity to see what happens.

Yes, my Rexx programs are tagged (IBM1047 and text), and yes, the 
auto-conversion incantations are active.  I thought I tried tagging as 
ISO8859-1 and text and it failed to execute a called Rexx program in the Unix 
directory with a WRONG.LENGTH.RECORD error, but I will repeat that test to 
verify.  At the time of that ISO8859-1 test I know I did NOT have the 
LRECL/RECFM override in place for the SYSEXEC allocation, so that may have been 
the problem rather than the file encoding.

I probably won’t be able to repeat these tests for at least a week because 
other tasks have priority, but I will report back after they are done.

I originally did not think of using LRECL/RECFM overrides on the SYSEXEC 
allocation because I thought they would be incompatible with the PATH keywords. 
 IBM could provide better and more complete examples of accessing Unix files 
from a TSO or batch task that show which DD keywords are compatible with Unix 
allocations, but I won't hold my breath waiting for such to be created.  There 
may be some table(s) somewhere (maybe in the JCL reference manual?) that show 
compatibility, but it's my fault that I haven't looked for them yet.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Saturday, October 8, 2022 7:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to use LISTDSI from Rexx under Unix shell?

On Sat, 8 Oct 2022 21:40:26 +, Farley, Peter x23353  wrote:

>Follow-up #2: I found out through further experimentation that there is an 
>ASSUMPTION of LRECL(80) RECFM(F) when SYSEXEC is a Unix directory, but you can 
>override that assumption by using LRECL and RECFM on the ALLOC for SYSEXEC:
>
>  "ALLOC FI(SYSEXEC) PATH('/u/tsouser/exec') DSNTYPE(HFS)" ,
> "PATHMODE(SIRUSR,SIXUSR) PATHOPTS(ORDONLY)" ,
> "FILEDATA(TEXT) PATHDISP(KEEP, KEEP) LRECL(4096) RECFM(V)"
> 
Attribute overrides have worked that way for a half century, longer than MVS 
UNIX has existed.

Does DSNTYPE(HFS) do anything, given that HFS is no longer supported?

PATH for SYSEXEC used not to work.  Apparently it has been fixed.

>EBCDIC encoding of the Rexx programs stored in the Unix directory is still 
>required.
>
Are your Rexx programs tagged with CCSID (ASCII, if you want), and have you 
issued the incantations to enable autoconversion?  If you have and it still 
doesn't work, an SR or an RFE is in order.

ISPF Edit recognizes and respects CCSID tagging of UNIX files, converting 
to/from your terminal CCSID.

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: 50 Years of SAS

[Mike Shaw]

Great stuff Barry. Brings back memories of the IBM world in the seventies.

Tony Barr went on to found Barr Systems. Mr. Barr's history of SAS is here:

http://www.barrsystems.com/about_us/the_company/sas_history.asp

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.


On Sun, Oct 9, 2022 at 12:26 PM Barry Merrill  wrote:

>   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 

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 

Can I supress BPXF024I ?

[Colin Paice]

I'm trying to get a TENET/PAGENT trace out.  Typical output is

*BPXF024I (TCPIP) Oct  9 15:55:20 TTLS 83951653 : 15:55:20 TCPIP 057*
EZD1286I TTLS Error GRPID: 001F ENVID: 0017 CONNID: 005D
LOCAL: 10.1.1.2..2023 REMOTE: 10.1.0.2..42870 JOBNAME: TN3270 USERID:
TCPIP RULE: TN  RC:  402 Initial Handshake 
005011421D10 

*BPXF024I text: Explanation*

*The text is the contents of the user's write buffer at the time of the
write request is displayed. Messages written to /dev/console by z/OS UNIX
applications appear on the MVS™ console in this message.*


The BPXF024I is not needed...  it tells me what I already know. Is there a
way of suppressing this?

Parts of TCPIP family write these to CTRACE - which is a faff start
writer, start trace... connect to TCPIP.. stop writer, stop trace, use IPCS
ctrace command.

Colin

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

Re: QWS3270 on zPDT

[Mike Shaw]

Binyamin,

The z/PDT emulator supports 3270E connection to the Linux side of the box.
If you have a 3270port statement in your IPL profile, it will specify the
local port number that you can use to connect to z/OS via the Linux side of
the box. That bypasses TCP/IP altogether. Mine specifies port 3270.

If you define a new session to QWS3270 and specify the name or IP address
of the Linux side of the box and a port number of 3270, you can connect
(non-securely) to that port and appear as a channel-attached local 3270 to
z/OS.

Does that method eliminate the problem you are seeing?

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.


On Sun, Oct 9, 2022 at 7:55 AM Binyamin Dissen 
wrote:

> On Fri, 7 Oct 2022 10:05:13 -0400 Mike Shaw 
> wrote:
>
> :>We use QWS3270 on a z/PDT and we have not seen that problem. Are you
> :>running as a locally attached 3270 device address or through TCP/IP
> :>remotely?
>
> TCP/IP, appears to be thru a gateway.
>
> :>On Fri, Oct 7, 2022, 6:17 AM Binyamin Dissen  >
> :>wrote:
>
> :>> I am having a strange issue running QWS3270 against a zPDT system (two
> :>> different systems). The screen goes completely blank after a few
> seconds of
> :>> inactivity.
>
> :>> Quick3270 Secure works fine.
>
> :>> Anyone else run into this?
>
> --
> Binyamin Dissen 
> http://www.dissensoftware.com
>
> Director, Dissen Software, Bar & Grill - Israel
>
> --
> 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 use LISTDSI from Rexx under Unix shell?

[Paul Gilmartin]

On Sun, 9 Oct 2022 12:51:07 +, Seymour J Metz wrote:

>The point that I am trying to make is that the behavior in question did not, 
>as claimed, go back half a century.
>
A half century ago, attributes specified to Allocation dominated attributes
intrinsic to the data set, and were in turn dominated by attributes coded
in the DCB.  That behavior has been preserved in the transition from
3350 to 3390, and to UNIX files.

>
>From:  Paul Gilmartin
>Sent: Sunday, October 9, 2022 8:40 AM
>
>On Sun, 9 Oct 2022 04:46:17 +, Seymour J Metz  wrote:
>
>>Anachronism alert! You wrote "Attribute overrides have worked that way for a 
>>half century, longer than MVS UNIX has existed." Half a century ago there was 
>>no PATH and no SDB. In fact, there was no SYSEXEC, only SYSPROC.
>
>And there was no 3390, but BLKSIZE=3120 still works.
>
>What point are you trying to make?
>
>
>From: f Paul Gilmartin
>Sent: Saturday, October 8, 2022 9:10 PM
>>
>In REXX, long ago, prior to SDB. I used to ALLOCATE PATH(whatever) ,
>LRECL(199) RECFM(V,B) ...
>and the REXX RTL would choose a reasonable BLKSIZE.

-- 
gil

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

Re: How to use LISTDSI from Rexx under Unix shell?

[Seymour J Metz]

The point that I am trying to make is that the behavior in question did not, as 
claimed, go back half a century.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Sunday, October 9, 2022 8:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to use LISTDSI from Rexx under Unix shell?

On Sun, 9 Oct 2022 04:46:17 +, Seymour J Metz  wrote:

>Anachronism alert! You wrote "Attribute overrides have worked that way for a 
>half century, longer than MVS UNIX has existed." Half a century ago there was 
>no PATH and no SDB. In fact, there was no SYSEXEC, only SYSPROC.

And there was no 3390, but BLKSIZE=3120 still works.

What point are you trying to make?


From: f Paul Gilmartin
Sent: Saturday, October 8, 2022 9:10 PM
>
In REXX, long ago, prior to SDB. I used to ALLOCATE PATH(whatever) ,
LRECL(199) RECFM(V,B) ...
and the REXX RTL would choose a reasonable BLKSIZE.

-- 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: How to use LISTDSI from Rexx under Unix shell?

[Paul Gilmartin]

On Sun, 9 Oct 2022 04:46:17 +, Seymour J Metz  wrote:

>Anachronism alert! You wrote "Attribute overrides have worked that way for a 
>half century, longer than MVS UNIX has existed." Half a century ago there was 
>no PATH and no SDB. In fact, there was no SYSEXEC, only SYSPROC.

And there was no 3390, but BLKSIZE=3120 still works.

What point are you trying to make?


From: f Paul Gilmartin
Sent: Saturday, October 8, 2022 9:10 PM
>
In REXX, long ago, prior to SDB. I used to ALLOCATE PATH(whatever) ,
LRECL(199) RECFM(V,B) ...
and the REXX RTL would choose a reasonable BLKSIZE.

-- gil

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

Re: QWS3270 on zPDT

[Binyamin Dissen]

On Fri, 7 Oct 2022 10:05:13 -0400 Mike Shaw  wrote:

:>We use QWS3270 on a z/PDT and we have not seen that problem. Are you
:>running as a locally attached 3270 device address or through TCP/IP
:>remotely?

TCP/IP, appears to be thru a gateway.

:>On Fri, Oct 7, 2022, 6:17 AM Binyamin Dissen 
:>wrote:

:>> I am having a strange issue running QWS3270 against a zPDT system (two
:>> different systems). The screen goes completely blank after a few seconds of
:>> inactivity.

:>> Quick3270 Secure works fine.

:>> Anyone else run into this?

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

Director, Dissen Software, Bar & Grill - Israel

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