HDTenEightyP/NetNews huggingface dataset:
Newsgroups: bit.listserv.ibm-main
Date:         Wed, 8 Apr 1992 14:29:00 EDT
From:         "John F. Chandler" <PEPMNT@CFAAMP.BITNET>
Subject:      Re: MVS and VM readable tapes (yes again :-( )

> What is the best way to write MVS readable tapes from VM?

The most accessible kind of tape is a standard-label tape.  For IBM
mainframes, that would be IBM standard; for other systems, ANSI standard.
You can write either kind on VM using SPRD2T, available from the VM-UTIL
file store found on several different LISTSERV's.  The nearest one to
Penn State is probably OHSTVMA.
                                            John
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Tue, 7 Apr 1992 01:04:00 PDT
From:         Leonard D Woren <LDW@USCMVSA.BITNET>
Subject:      Re: PIPE Dreams?

On Mon, 6 Apr 1992 23:47:50 EDT,
   "A. Harry Williams" <HARRY@VM.MARIST.EDU> said:
> But is it supported?  Who will accept APARS on it under TSO?

No.  "Problems must be recreated in a supported environment."  I.e.,
CMS.  Interesting that PIPE HELP contains references to running PIPES
on MVS!  I wish I could figure out how to get PIPE HELP to run on MVS.

/Leonard
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Wed, 15 Apr 1992 08:22:39 CST
From:         NREEVES@TWSUVM.BITNET
Subject:      Re: Power networking requirements
Comments: cc: NELSON@TWSUVM.BITNET

Larry, yes, you can connect Power and RSCS.

You have to assemble 2 tables in VSE, PNET and PNODE defining the connection
to RSCS. In VM you have to define the VSE node to RSCS. The two virtual
machines also have to be connected via a CTCA.

The Power stuff is described in the Power Administration & Operation manual.
The RSCS stuff goes in the CONFIG file: You need a LINK for a NJE line, and
a PARM also. I don't know the exact name of the RSCS manual, but the one
that describes the CONFIG file & it's statements would be the one.

This is how we have 5 vse machines communicating with rscs. If you
would like detailed help setting it up, send me a private note.

Nancy Reeves

Techincal Support Analyst        bitnet: nreeves@twsuvm
Wichita State University         internet: nreeves@twsuvm.uc.twsu.edu
Newsgroups: bit.listserv.ibm-main
From: mrl@uai.com (Mark R. Ludwig)
Subject: Re: User interface under TSO
Organization: Universal Analytics, Inc., Torrance (LA), CA
	<RNETMAIL9204030812430SEB1525@MVS.DRAPER.COM>
Date: Tue, 7 Apr 92 01:10:20 GMT

In article <RNETMAIL9204030812430SEB1525@MVS.DRAPER.COM> "Stephen E. Bacher" <seb1525@MVS.DRAPER.COM> writes:

   >It will be fairly easy to write the output routine and the prompting
   >routine in assembler.  The one thing I'm not sure about is the
   >difference between the TPUT/TPG macros and the PUTLINE/PUTGET macros,
   >other than that the latter are newer and PUTGET supports "print
   >inhibit," which is something I need for password prompting.

   Not quite right.  Both the T... and P... macros support "print inhibit"
    - you specify the ASIS option on TPUT or PUTLINE or PUTGET and put a
   hex 24 character at the end of your prompt.  Depending on whether you
   have TCAM or VTAM, and maybe on the version/release level, you may or
   may not need to include a hex 15 for a newline if you want one.

Hmmm, I assume this X'24' is documented somewhere.  I'm under enough
time pressure that I might just use it, but it makes me awfully
nervous to be putting such an incantation into a program if it is not
documented as being a "customer interface" in the manuals.  Perhaps
I'm more worried about such things than I should be.  I'd be somewhat
less worried if the first customer were domestic.  If the customer has
some unexpected configuration which doesn't support the X'24',
debugging this over the Atlantic would be unpleasant.

   >             An IBMer suggested that the Txxx macros are "easier" to
   >use, but I don't see that from the macro descriptions.

   They are far, far easier to use.  Interestingly, the manual has never
   suggested this; the way it's written, you would think that the T...
   macros are some hairy obscure interface.

Agreed.  Can you give me a clue why the T... macros are actually
easier?  The only thing I can figure is that perhaps the IOPL has to
be tweaked in non-obvious ways, or some such.$$
-- 
INET: mrl@uai.com      BANG: uunet!uaisun4!mrl      ICBM: USA; Lower Left Coast
                            "Seize the day next week at the latest." -- Boynton
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Tue, 14 Apr 1992 13:58:08 G+3
From:         "Saad M. Al-Harthi (02) 695-2211" <CCA3407@SAKAAU03.BITNET>
Subject:      GRS problem.

 Hello all,
    We have an ES9000/210 and we are currently running MVS/ESA 4.2.0
on first LPAR, actually we plan to install VM/ESA and a second MVS
as a gest operating system in the second LPAR to make use of GRS
to connect the two systems together the problem is I can not figure
out how to connect a stand alone machine with a gest machine?.

Any comments or help will be apeatuated.
Thanks in advanced.

------------------
Saad Al-Harthi
MVS system's Engineer
KAAU, Jeddah, SA.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: New York University - University Computer Center
Newsgroups: bit.listserv.ibm-main
Date:         Tue, 7 Apr 1992 18:39:44 GMT
From:         Craig Barefield <URWCB@NYUCCVM.BITNET>
Subject:      GMT/LOCAL Clocks

Just one comment besides the excellent ones that have already been made,
is that of course a program can also issue the TIME macro with the GMT
option.  If you run with GMT=LOCAL such as we do now, changing to an
offset will show you which programs do such things as this.
However they may not immediately be apparent to you.  Eg-if a program
that cuts some smf records with timestamps in the record to do some sort
of chargeback, it will work correctly, however the time that the event
occurred will be GMT not local time.  That may not be what you expect.

I know that a SET CLOCK backward or forwards causes some real nice
charging in our home-grown accounting system, so we always ipl to
implement time changes.

I have heard of applications that use GMT time when communicating
with other computers in other timezones in order to synchronize
transactions that need a standard point of reference in time, GMT!

Since we have run like this, GMT=LOCAL forever, I often debate with
myself if I should change it or not and face the consequences of
the programs that *may* use GMT versus Local.  Since we run a MVS
guest under VM and if you do time zone offsets, I dont know which
time the MVS guest would see.  GMT or Local?  If it were GMT then
I would have to also put in the offset in the MVS CLOCK parmlib
parameter.  (If I were really all that curious, I will try it someday ;-) )

Just my $.02 worth!  Have fun all!

Craig Barefield
Technical Services Project Leader
New York University
University Computer Center
715 Broadway - 9th Floor
New York  NY  10003
(212) 998-1156
Bitnet: URWCB@NYUCCVM
        URWCB@UCCVM.NYU.EDU
Date: Thursday, 16 Apr 1992 00:27:49 EDT
From: Jerry Bryan <BRYAN@wvnvm.wvnet.edu>
Newsgroups: bit.listserv.ibm-main
Subject: Re: MVS Jobname Conventions


I think that IBM should be applauded for finally supporting the concept
of ownership of objects in the JES queues.  However, I think it is
fair to say that the problem is not fully solved just by fixing JES
and RACF.  Much other code needs to exploit the new facilities.  The
discussion about SDSF exemplifies this need.  Another example is that
TCP/IP for MVS has an interesting job submission and retrieval interface
into JES, but it seems to depend on the old TSO style jobname convention
rather than upon the new JES/RACF ownership concept.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Mon, 13 Apr 1992 14:23:39 PLT
From:         Dave Gibney <GIBNEY@WSUVM1.BITNET>
Subject:      Controlling Various ISPF primary menus

   We are in the process of expanding our use of TSO/ISPF. Most MVS editing and
 RJE is now done via OBS-WYLBUR.
   The expanded user group of TSO will have different needs and skil levels.
   What are suggested ways of providing different primary option menus to
 different people. Very few people will need CA-ACTIVATOR as an example.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Wed, 8 Apr 1992 07:57:51 CDT
From:         Tim Haiar <THTJ18@SDNET.BITNET>
Subject:      Re: Clear Screen for USSTA
              7 Apr 1992 10:10:00 LCL from <LONGLEGS.SYSTEMS@MHS.UNC.EDU>

On Tue, 7 Apr 1992 10:10:00 LCL LONGLEGS said:
>When I set up USSTAB's for our SNA terminals, I set up a USS10 message that
>covered all 24 lines of the terminal to get around this problem.  This
>worked pretty well.  Obviously USSTAB's are a poor substitute for a VTAM
>menu, and we eventually implemented a menu program.
>
>-Joel Dunn
> UNC-CH Administrative Data Processing
Where did you leave the cursor for the user to type there response? My message
covers all 24 lines but it does not fill up the 24th line, so my next USS
message is starting halfway through the 24th line.

- Tim Haiar
- State of South Dakota - Board of Regents
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Mon, 6 Apr 1992 14:33:00 PDT
From:         Leonard D Woren <LDW@USCMVSA.BITNET>
Subject:      Re: PIPE Dreams?

On Sun, 5 Apr 1992 16:19:16 GMT,
   Paul Gilmartin <pgilmart@ISIS.CS.DU.EDU> said:
> ... When may I expect to see compatible MVS/TSO PIPES?

At the recent SHARE, I wrote and submitted a requirement for PIPES on
TSO.  In a session on Friday morning (the third one of something like
"Look What we Found in the Bit Bucket"), they mentioned that CMS PIPES
runs on TSO.  Go to your PIPES maint disk and run the PIPGMOD exec.
Ship the resulting object deck over to MVS and linkedit it.  You now
have PIPES, but without any help and without any support.  Also, you
have to be licensed for PIPES on that machine.  We run MVS under VM,
so we have no licensing problem.  Now, what can I use it for?

/Leonard
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Tue, 14 Apr 1992 08:01:21 EDT
From:         Ken Koester <MAINT2@ERS.BITNET>
Subject:      Re: COBOL

On Fri, 10 Apr 1992 00:32:00 PDT Leonard D Woren said:
>
>While it is certainly true that more C programs than COBOL programs
>are unintelligible, I think that a good programmer can write a good
>program in any language, and a lousy programmer can write a bad
>program in any language.

Undeniably true. . . but some languages (insert your own favorites here)
are easier to be unintelligible in than others.
>
>. . . .  I've seen numbers in trade journals claiming that 80-90% of
>programmer time in commercial shops is spent maintaining old COBOL
>programs.

This number would be more meaningful if we knew how much time in general
programmers spend maintaining old code, i.e., if the commercial shops used,
say, C, or PL/I, or Modula-2 or whatever, wouldn't they still be spending
80% of their time maintaining old code?  The fact that it's COBOL code they
maintain is an artifact of what went on before, not that COBOL is inherently
poor as a programming language.

+----------------------------------------------------------------------+
| Ken Koester, Systems Programmer  | BITNET:  MAINT2@ERS               |
| US Department of Agriculture     | Tel:     (202) 219-0577           |
| Economic Research Service        | Fax:     (202) 219-1292           |
| Data Services Center             |          (ATTN: Rm 110)           |
+----------------------------------------------------------------------+
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Fri, 10 Apr 1992 00:32:00 PDT
From:         Leonard D Woren <LDW@USCMVSA.BITNET>
Subject:      Re: COBOL

> well, i don't want to begin a cobol vs any other language war, but...

Well, I don't either... and just replying to the previous posting on
this subject creates that risk, but here goes.

While it is certainly true that more C programs than COBOL programs
are unintelligible, I think that a good programmer can write a good
program in any language, and a lousy programmer can write a bad
program in any language.  When I look at some of my 15-20 year old
assembler, I think "who wrote this junk?  Oops, I did."  But for
readability, I'll pit some of my current assembler language programs
against most COBOL programs which exist in business shops.  The
primary cause of unreadable programs is inadequate comments.  COBOL in
a sense reduces the need for comments by requiring the programmer to
be very wordy in the code itself.  In my (small) experience reading
COBOL programs, I'd say that most cobol programmers must not know how
to put in comments.  But it's a known fact that most APL programmers
don't even know that you *can* comment an APL program, let alone how.
For all I know, C programmers break out in hives when they try to type
/* ... */ .  And there's someone on the net somewhere with a sig line
stating "From an examination of C programs, the comment must be the
most difficult to use."

But so what if COBOL programs are more readable even if the comments
are missing?  The productivity loss from all that COBOL is probably
massive.  I've seen numbers in trade journals claiming that 80-90% of
programmer time in commercial shops is spent maintaining old COBOL
programs.  It takes much too long to decipher someone else's COBOL
program logic just to make a small change.  I claim that this is less
of a problem in most other languages.  Often a program is rewritten
from scratch rather than modifying the logic because the existing
program can't be understood.  And that *is* quite often specifically
because it's in COBOL.  I've patched programs in a number of languages
that I didn't know, but I was never able to do that with a COBOL
program.  Only in the very latest COBOL do certain critical language
constructs even exist.

BTW, I'm not defending C.  I think C is the perfect language for *ix,
an operating system which was designed to be obtuse.

Before you hit that reply key, remember that I wear asbestos clothes.
;-)

/Leonard
Date:    Fri, 10 Apr 92  0:31 PDT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Mon, 13 Apr 1992 20:23:00 PDT
From:         Leonard D Woren <LDW@USCMVSA.BITNET>
Subject:      Re: Catalog error

ISPF isn't supposed to let you delete a vsam object using "d" from 3.4
or 3.2 .  If you were able to do so, something is wrong.

Try "DELETE xxx NOSCRATCH" to remove the catalog entries for objects
that don't exist.  To remove the bogus data component name from the
catalog if it doesn't go away when you delete the bogus cluster name
(or if there is no cluster entry in the catalog), use "DELETE xxx
TRUENAME NOSCRATCH".  (I think that combination of operands is
allowed...)

>    What I really need is help in cleaning this up. Any suggestions???
> Can I do an export and import, or do I need to re-build the catalog.

It's usually dangerous to export a KSDS that has key sequence errors.
You may not get the whole thing.  (An ICF catalog is just a KSDS
that's flagged as being a catalog.)

> Also, any ideas on how this could happen. The system is MVS 3.1.3.

Interrupted updated processes, like a cancel/force or a system crash
during a CI split, for example.  Also, we had similar problems while
we had catalogs on a Memorex 3880-23 look-alike.  When the controller
went away, so did those problems.  (So did the mysterious bug of the
format 1 dscb for SYS1.UADS being zeroed out inexplicably.)

/Leonard
Organization: City University of New York/ University Computer Center
Date: Wednesday, 8 Apr 1992 12:23:03 EDT
From: Aron Eisenpress <AFECU@CUNYVM.BITNET>
Newsgroups: bit.listserv.ibm-main
Subject: Re: Service-only CBPDO Subscription Offering and MVS PUTs

I intend to keep getting the MVS PUTs, at least for the time being.  The
disadvantage, to me, of CBPDO by subscription is that CICS, NCP, and MVS
would come on separate tapes; with PUT they're all on the same tape.  For
archival purposes this is more of a pain to manage.  We do keep our service
level quite current on the MVS SCP, and with the ability to download the
buckets from IBMLink I just don't see much difference in usability between
PUT and CBPDO.
-------

 -- Aron Eisenpress, City U of NY
    (AFECU@CUNYVM.BITNET, or AFECU@CUNYVM.CUNY.EDU on the Internet)
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Thu, 9 Apr 1992 11:42:54 EDT
From:         Walt Farrell <wfarrell@VNET.IBM.COM>
Subject:      MVS Jobname Conventions
Comments: To: ibm-main%RUTVM1.bitnet@cunyvm.cuny.edu

On 6 Apr 1992 at 16:30:16 EST, Matt Simpson <SYSMATT@UKCC.UKY.EDU>
wrote:

> I realize that in the past, many TSO shops have required all jobs
> submitted via TSO to have a jobname consisting of the userid plus 1
> character. Much of the default security in TSO and SDSF still seems to
> follow this convention. We have had a few complaints, and will probably
> have more, from new TSO users who have not had this restriction under
> CMS, and don't like it under TSO.
> What are other TSO/SDSF shops doing out there?  Are you still requiring
> jobs to be the userid plus 1 character? If not, how are you identifying
> the "owner" of a job to determine who is allowed to view/print/delete
> it?

In case you aren't aware of it, beginning with MVS/ESA 3.1.3, JES2 3.1.3,
RACF 1.9, and SDSF 1.3.1 there is a true concept of job ownership.  JES2
knows who the owner of a job is, and who the owner of the sysout files
for a job is, and security is managed through the System Authorization
Facility (SAF) and RACF.  SDSF can also make use of the new security
functions of MVS, JES, and RACF with the result that you don't normally
need to restrict the job names that your users use.  TSO/E 2.1.1 also
supports this new security, and can be configured so that the OUTPUT and
CANCEL commands will work with job names that don't start with the userid.

  Walt Farrell, RACF Design & Planning, IBM
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: ELM [version 2.2 PL15]
Newsgroups: bit.listserv.ibm-main
Date:         Fri, 10 Apr 1992 09:42:01 EDT
From:         Mott Given <ntm1169@DSACG3.DSAC.DLA.MIL>
Subject:      CICSPARS reports
Comments: To: IBM Mainframe List <ibm-main@vm1.cc.uakron.edu>

   I am puzzled by the PERFORMANCE TOTALS REPORT that I am getting from
CICSPARS V1R1.  They are reports for a system running CICS 2.1, DB2 2.2,
under ESA 3.1.0E.  I add the following fields and they come out greater than
the total CPU time reported for the PGN that the CICS region is running in:
   TOTAL CICS TIME (KCP + TCP + JCP)
   TOTAL SUBTASK TIME

I thought the TOTAL SUBTASK TIME would be recored in the same PGN (performance
group) that the CICS region was running in?
Also, is it correct to assume that the DB2 time charged back to CICS and
the VSAM subtasking is charged to the field "TOTAL SUBTASK TIME"?


Mott Given @ Defense Logistics Agency Systems Automation Center,
             DSAC-TMP, Bldg. 27-1, P.O. Box 1605, Columbus, OH 43216-5002
INTERNET:  mgiven@dsac.dla.mil   UUCP: ...{osu-cis}!dsac!mgiven
Phone:  614-238-9431  AUTOVON: 850-9431   FAX: 614-238-9928
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Mon, 13 Apr 1992 20:15:00 PDT
From:         Leonard D Woren <LDW@USCMVSA.BITNET>
Subject:      Re: User interface under TSO

On Mon, 13 Apr 1992 08:06:00 EDT,
   "Stephen E. Bacher" <seb1525@MVS.DRAPER.COM> quoted me:
> >                         my gripe is specifically that the terminal
> >name is not available to a problem program.
Then wrote:
> If you have ACF2, you can get the terminal name from the ACFASVT for
> the TSO user.  Of course, this requires code to search the subsystem
> table for the ACF2 subsystem and index into the ACFASVT, etc., etc.

That code is easy.  It's just not portable.  What happens when we
junk acf2 next fy because we can get racf for free through the hesc?

/Leonard
Organization: Youngstown State University
Date: Wednesday, 8 Apr 1992 10:19:40 EDT
From: Troy Allen Cross <TAC@ysub.ysu.edu>
Newsgroups: bit.listserv.ibm-main
Subject: Service-only CBPDO Subscription Offering and MVS PUTs

Recently, I received literature from IBM called "Service-only CBPDO
Subscription Offering and MVS PUT Discaontinuation Option".

I was wondering what other MVS sites are doing about this.

I am considering doing one of the following:

(1) Discontinue getting the MVS PUTs,
    order a current CBPDO (to avoid receiving two years of service),
    and subscribing to the service-only CBPDO.

or

(2) Discontinue getting the MVS PUTS,
    order a current CBPDO (to avoid receiveing two years of service),
    and just ordering the CBPDO as needed.

What do you think?

I have rarely used the MVS PUT tapes.  However, they are nice to have
around when a third party product is updated and is hit by a known
problem (PTF) that hasn't been applied yet.

Usually, I order and install a MVS and CICS CBIPO every 12 to 18 months.

How many service-only CBPDOs do you get per year?  1, 2, 3, or 4?

How do you handle the situation where you get service-only CBPDOs
in January, April, July, and October and you receive October's CBPDO
before you have installed July's?

************************************************************************
* Troy Allen Cross                                                     *
* Software Specialist (MVS/XA & CICS/MVS SYSPROG)                      *
* Youngstown State University                                          *
* 410 Wick Avenue                                                      *
* Youngstown, OH 44555-3036                                            *
* A.K.A. on Bitnet as TAC@YSUB and Internet as TAC@YSU.EDU             *
************************************************************************
Newsgroups: bit.listserv.ibm-main,bit.listserv.script-l
From: pgilmart@isis.cs.du.edu (Paul Gilmartin)
Subject: PIPE Dreams?
Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
Date: Sun, 5 Apr 92 16:19:16 GMT


Several of my colleagues are evangelizing for CMS PIPES.  I regard this
PRPQ as more interesting than useful until there is PIPE support for some
of my favorite applications.  Does anyone know when we may expect PIPE
support for such products as:

    DCF                      (5688-015)
    PostScript Interpreter   (5688-104), and
    PSF                      (whatever) -- of course, I mean the CMS user
                                        interface rather than the printer
                                        driver itself.

My motive should be obvious -- I'd like to be able to use any two or all
three of these products in concert without the enormous temporary DASD
storage they require.

Likewise, I cherish portability.  When may I expect to see compatible
MVS/TSO PIPES?

Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU