subject:"Re\: IF \(was\: Aging ...\)"

On Fri, 8 Nov 2013 10:58:46 +0100, Bernd Oppolzer wrote:

( I have this problem sometimes, because management
decides that some of our mainframe based test supporting
C programs should be moved to Linux 64 on Intel).

For now, the solution is

#ifdef MAINFRAME
   fopen /* this way */
#else
   fopen /* the other way */
#endif
 
An unforseen and unfortunate consequence of too-early
binding to the file naming conventions of a particular OS.

But, yes, environment variables:

fopen( getenv( SYSUT1 ), getenv( SYSUT1_OPTS ) );

... where, outside the C program, for z/OS:

SYSUT1=//DD:SYSUT1 export SYSUT1

... and for Linux:

SYSUT1=/home/$LOGNAME/sysut1 export SYSUT1

... and whatever is necessary for the OS-dependent options.

(It would be useful if the syntax of DD were extended to
allow the options to be embedded in the TIOT entry.
Do PATHOPTS, PATHMODE, and FILEDATA provide sufficient
support already?  More likely for UNIX files than for legacy
data sets.)

-- gil

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

Re: IF (was: Aging ...)

On Fri, 8 Nov 2013 09:06:20 -0600, Joel C. Ewing wrote:

 ... Placement in the JCL  (from memory) ...

An IF/THEN/ELSE/ENDIF statement construct can appear anywhere in the
job. However, an IF statement specified before the first EXEC statement
in a job is not evaluated before the first step executes. If the IF
statement applies to later steps in the job, the statement will be
evaluated when the system decides whether to process the later steps.
 
Thanks for jogging my memory; I stand corrected.

So they don't disallow use of IF prior to first EXEC, it just works
inconsistently (compared with usage of IF elsewhere).  ...

It's still BAD.  But what operand of IF can legally and usefully
be coded before the first EXEC?  One might imagine:

//* (Might come from an INCLUDE member.)
//  SET DOIT='TRUE'  /* 'FALSE' to skip STEP.  */
//*
//L  IF ( DOIT ) THEN  /* Unsupported, but no warning issued.  */
//STEP  EXEC PGM=IEHINITT ...  /* My favorite conditional step.  */
//L2  ENDIF

The JCL Ref states that construct does not produce predictable results
(again, from fading memory).  The spec should be tightened.  The
behavior on the first step should be made consistent, and the JCL Ref
should be updated to describe the current useful behavior of IF for
other steps.

-- gil

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

Re: Aging Sysprogs = Aging Farmers

2013-11-08 Thread Anne Lynn Wheeler

shmuel+ibm-m...@patriot.net (Shmuel Metz  , Seymour J.) writes:
 Due to the NIH syndrome, VPAM and VIPAM cannot be imported from TSS.
 However, I can provide you with a subroutine for the functionality of
 BLDL, FIND and STOW for QSAM, with a single OPEN for multiple members.
 You'd have to refit it for current releases.

note that this is account of one of the primary people responsible for
HASP ... then did a group that did something similar for MFT that he
called RASP ... the results was used as part of the justification for
moving to virtual memory for all 370s.
http://www.garlic.com/~2011d.html#73

however, in part because company wouldn't go ahead with it (possibly
also nih) ... he left and redid it at Amdahl (from scratch in clean
room) ... and even tho IBM wasn't to going to do anything with it
... there was still litigation and court ordered code examination
... which only was able to find a few lines of code that could be
considered similar.

Note that later ATT had contracted with ibm to do a stripped down
TSS/370 kernel called SSUP which unix infrastructure was layered on top.

There was somebody still at univ. that had done a native port of unix to
370 ... and there was attempt to hire him in ibm ... but wasn't
succesful and he went to amdahl where UTS was done instead.  I knew
some of the people involved in both projects and there was some about of
internel politics and I got asked about it ... so i suggested that they
try and meld the projects ... somewhat along the lines of TSS SSUP for
ATT ... which never happened. UTS during development was referred to
as GOLD for the element Au (or amadahl unix).

As an aside, when i was undegraduate, the univ. was talked into
upgrading 709/1401 combo to 360/67 supposedly for tss/360 ... however at
the time, tss/360 never really came to anywhere near production and the
360/67 ran mostly as 360/65 with os/360 ... i got undergraduate job
responsible for carefeeding of the system. Jan1968 people from science
center to install cp67. I got to play with cp67 on weekends ... when i
wasn't doing os/360 maint. post with fall 1968 share presentation about
some of the os/360 work (careful reorder of stage2 sysgen cards to
optimally place datasets and pds members that improved univ. student
fortran job throughput by nearly three times) and cp67 (work) rewrote
lots of cp67 that drastically cut pathlenth/overhead.
http://www.garlic.com/~lynn/94.html#18

however, sometimes on weekends, i had to work around ibm se playing with
tss/360. We did setup common benchmark for fortan edit, compile and
execute with simulate scripts and simulated users. turns out that cp67
with 35 simulated users running the script outperformed and had better
interactive response than tss/360 with only 4 users running the same
script. In any case, i learned quite a bit about how tss/360 did things
wrong.

later at science center ... i did a paged mapped filesystem for cp67/cms
avoiding a lot of tss/360 performance issues (it was also somewhat in
competition with the multics group on the 5th flr that was also doing
paged mapped filesystem).

I've mentioned before about ridiculing the FS effort ... in part because
they were somewhat doing the tss/360 filesystem organization ... w/o
addressing many of the performance issues.
http://www.garlic.com/~lynn/submain.html#futuresys

later when future system emplodes and the mad rush to get products back
into 370 product pipeline ... that contributed to release some of the
360/370 stuff all during the FS period ... recent reference
in this thread
http://www.garlic.com/~lynn/2013n.html#22

... but not the page mapped stuff ... presumably because page-mapped
filesystem was tainted with both tss/360 and FS efforts ... even tho i
could show three times greater throughput with cms paged-mapped
filesystem compared to standard cms filesystem (on the same hardware)
past posts mentioning page mapped filesystem 
http://www.garlic.com/~lynn/submain.html#mmap

misc. past posts mentioning tss/370 ssup effort for att unix:
http://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development 
Philosophy
http://www.garlic.com/~lynn/2005b.html#13 Relocating application architecture 
and compiler support
http://www.garlic.com/~lynn/2005d.html#61 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005s.html#34 Power5 and Cell, new issue of IBM 
Journal of RD
http://www.garlic.com/~lynn/2006f.html#26 Old PCs--environmental hazard
http://www.garlic.com/~lynn/2006m.html#30 Old Hashing Routine
http://www.garlic.com/~lynn/2006p.html#22 Admired designs / designs to study
http://www.garlic.com/~lynn/2006t.html#17 old Gold/UTS reference
http://www.garlic.com/~lynn/2007.html#38 How many 36-bit Unix ports in the old 
days?
http://www.garlic.com/~lynn/2007b.html#3 How many 36-bit Unix ports in the old 
days?
http://www.garlic.com/~lynn/2007k.html#43 John W. Backus, 82, Fortran 
developer, dies
http://www.garlic.com/~lynn/2007m.html#69 Operating systems are old and busted

Re: IF (was: Aging ...)

On Fri, 8 Nov 2013 15:09:59 +, Martin Packer wrote:

What do we suppose the intended use cases were for this?
 
I suspect there was no discernible intent.  More probably, in my
conjecture, prior to the advent of IF, there was a subroutine to
evaluate the COND parameter and determine whether to skip the
step.  As a performance feature that I'd deem gratuitous, that
subroutine was bypassed for the first step.  When IF was provided,
the logical place to add the code appeared to be in that COND
subroutine which is not entered for the first step.

Or, perhaps the intent was to make the behavior of IF consistent
with COND.  ObEmerson.

Much of this could be repaired since the JCL Ref states that the
behavior of unspecified IF constructs is unsupported and subject
to change.  Customers have been forewarned.

-- gil

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

Re: Aging Sysprogs = Aging Farmers

On Thu, 7 Nov 2013 22:36:30 -0800, Jon Perryman wrote:

As for concatenating an MVS dataset before the UNIX file isn't as ironic as it 
seem's. This actually occurs more often than you think. The classic example is 
specifying a block size on the first dataset that is larger than it's block 
size.

Perhaps by programmers who don't understand that it suffices to
specify an overriding BLKSIZE on the DD statement.  Or is there
some context where the concatenation is necessary.

That is exactly what is happening with the UNIX file. UNIX files don't support 
an
RECFM, LRECL or BLKSIZE so specifying them on the DD results in them being 
ignored. 

Utterly false!  Have you never tried it, nor read the JCL Reference?  I do
it routinely, and it works very well on, for example on SYSUT1 for IEBGENER;
no concatenation required.

When the first DD specifies a dataset that supports RECFM, LRECL and BLKSIZE,
AMATERSE now has information it needs. Secondary DD's are not scrutinized as 
much as the first dataset in a concatenation.

Fortunately, it's better than it used to be.  Long ago, the BLKSIZE of the first
catenand dominated; nowadays the maximum prevails.

Maybe GIMZIP (from SMP/E) or zip from the UNIX utilities page might help.

I doubt that either of these is capable of understanding an AMATERSE
archive, but I haven't tried it, so here I'm speaking from ignorance.

-- gil

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

Re: Aging Sysprogs = Aging Farmers

2013-11-08 Thread Jon Perryman

For concatenating dataset overrides not being ironic. I gave an example the 
first DD of a concatenation determining the attributes of the open. 
Concatenation is not a requirement but in this instance, it helped because it 
allowed AMATERSE to obtain the attributes it needs.

I admit I don't re-read JCL and I mostly use existing JCL. But that doesn't 
make my statement false. For LRECL, it clearly states LRECL applies to data 
sets with the BPAM, BSAM, EXCP, QISAM, QSAM, and TCAM access methods, and with 
SMS, to VSAM data sets.. Just because UNIX files are implemented thru one of 
these, doesn't mean UNIX files are that access method. It later states in 
OVERRIDES LRECL overrides the record length specified in the data set label. 
UNIX files don't have a data set label or lrecl. IBM modified IEBGENER (and 
other utilities) to support DCB for UNIX files so yes they do work. I brought 
up IEBGENER with regards to VSAM to show that not all dataset types are 
supported. I did not say anything about IEBGENER supporting UNIX files.

As for mentioning GIMZIP and ZIP, I was proposing them as alternatives to 
AMATERSE. Since there wasn't any context, I made a false assumption.

Jon Perryman.




 From: Paul Gilmartin paulgboul...@aim.com
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, November 8, 2013 8:58 AM
Subject: Re: Aging Sysprogs = Aging Farmers
 

On Thu, 7 Nov 2013 22:36:30 -0800, Jon Perryman wrote:

As for concatenating an MVS dataset before the UNIX file isn't as ironic as 
it seem's. This actually occurs more often than you think. The classic 
example is specifying a block size on the first dataset that is larger than 
it's block size.

Perhaps by programmers who don't understand that it suffices to
specify an overriding BLKSIZE on the DD statement.  Or is there
some context where the concatenation is necessary.

That is exactly what is happening with the UNIX file. UNIX files don't 
support an
RECFM, LRECL or BLKSIZE so specifying them on the DD results in them being 
ignored. 

Utterly false!  Have you never tried it, nor read the JCL Reference?  I do
it routinely, and it works very well on, for example on SYSUT1 for IEBGENER;
no concatenation required.

When the first DD specifies a dataset that supports RECFM, LRECL and BLKSIZE,
AMATERSE now has information it needs. Secondary DD's are not scrutinized as 
much as the first dataset in a concatenation.

Fortunately, it's better than it used to be.  Long ago, the BLKSIZE of the 
first
catenand dominated; nowadays the maximum prevails.

Maybe GIMZIP (from SMP/E) or zip from the UNIX utilities page might help.

I doubt that either of these is capable of understanding an AMATERSE
archive, but I haven't tried it, so here I'm speaking from ignorance.

-- 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: Aging Sysprogs = Aging Farmers

On Fri, 8 Nov 2013 10:49:15 -0800, Jon Perryman wrote:

... IBM modified IEBGENER (and other utilities) to support DCB for UNIX files 
so yes they do work.

I strongly doubt that although I haven't access to the source code to verify it.
Rather, I understand that the support was entirely in the access method so
that legacy applications using OPEN, GET, PUT, READ, WRITE, and CLOSE
continue to work unmodified.  Perhaps one of the assembler experts such
as Ed or Mark might supply a concurring or dissenting opinion.

Some applications that showed data set names in their SYSPRINT were slightly
modified to show the pathname instead of a 44-character dummy supplied by
the OS somehow.

For an application to restrict itself to a subset of device types is a 
misdesign.
Rather the application should specify its access method requirements and let
the access method deal with device types.

-- gil

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

Re: Aging Sysprogs = Aging Farmers

2013-11-08 Thread Ken Brick


On 8/11/2013 09:51 AM, John Gilmore wrote:

About QDAM, I should perhaps have made it clearer that my student was
having me on.

John Gilmore, Ashland, MA 01721 - USA

John,

You disappointed me. I fully expected that you would assigned the 
student the task of writing the functional specs, in line with QSAM, 
BSAM and BDAM, and then asked him to implement QDAM


--
Ken

Mob: 0409 009 764

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

Re: Aging Sysprogs = Aging Farmers

2013-11-08 Thread Jon Perryman

I suspect that you are correct that the I/O macro's have some sort of DCB 
support built in rather than changing IEBGENER. IBM specifically states that 
UNIX files are supported in some way in BSAM, QSAM, BPAM, and VSAM. It also 
says that certain macro's have restrictions and incompatibilities but only 
lists a couple examples. UNIX support in these macro's has never been a 
priority for me.

 Jon Perryman.




 From: Paul Gilmartin paulgboul...@aim.com

On Fri, 8 Nov 2013 10:49:15 -0800, Jon Perryman wrote:

... IBM modified IEBGENER (and other utilities) to support DCB for UNIX files 
so yes they do work.

I strongly doubt that although I haven't access to the source code to verify 
it.
Rather, I understand that the support was entirely in the access method so
that legacy applications using OPEN, GET, PUT, READ, WRITE, and CLOSE
continue to work unmodified.  Perhaps one of the assembler experts such
as Ed or Mark might supply a concurring or dissenting opinion.


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

Re: Aging Sysprogs = Aging Farmers

2013-11-07 Thread David Crayford

On 7/11/2013 10:10 AM, Don Poitras wrote:

In article 4212144266386912.wa.paulgboulderaim@listserv.ua.edu you wrote:

On Wed, 6 Nov 2013 15:02:48 -0800, Frank Swarbrick wrote:

Does anyone actually run X-Windows on z/OS?? Seems to me GUI things such as the
Explorer tools, the Debug Tool (and other Productivity Tools) GUI, etc., and
even RDz could be well served by being X-Windows client applications.? But what
do I know...

I had xterm (and xlogo) working several years ago. Today, SSH tunneling
isn't working for me. I can't justify making its repair a priority for our
admins (my judgment; I haven't requested it).
A while back I discovered a directory of the customary Java GUI demo
applets. I asked here if anyone had got them to work. The only answer
tendered here was to serve them with HTTPD and let the desktop
browser client do the rendering. Not the answer to the question I meant
to ask.
I have some vague recollection that SAS had a GUI remote debugger in
connection with their cross compiler. And it would seem to be a natural
for the Colesoft tools.
-- gil

We have a GUI debugger, but it runs on Windows (not X11) and was never
sold commercially. Some versions of SAS require X11 for some install
programs. I know some people that actually like to use nedit on zos.
I guess our box is big enough that it works well enough to be an
alternative to things like vi or ISPF. I just tried it out using the
X11 server running on OSX from home and it seems just as peppy as using
any native OSX editor editing a local file.

That's interesting! I remember in the early 2000's Slickedit had an X-11
mainframe port. It was withdrawn from marketing pretty quickly due to
poor performance. It was much cheaper (and easier) to just use FTP or
mount a network file system. IIRC, one of the big bottlenecks was the
context assist tagging engine chomping huge amounts of CPU for
auto-completion.

RDz et all use z/OS servers which just serve files which get mapped to
directories on the PC. I think this is the way to go. Networks are fast
and PC's are cheap.

I've always wondered why I can compile a C++ program on my PC in seconds
and it takes minutes on an idle z114?

http://www-03.ibm.com/systems/z/os/zos/features/unix/library/IBM+Redbooks/index.html#nedit

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

Re: Aging Sysprogs = Aging Farmers

2013-11-07 Thread David Crayford


On 7/11/2013 2:32 AM, Paul Gilmartin wrote:

On Wed, 6 Nov 2013 10:06:39 -0800, Jon Perryman wrote:


JCL not having loop capabilities has nothing to do with rewinding card readers.


*I* believe he was being facetious.


Yes! I do have a propensity for being flippant.

IIRC, Brooks regretted that JCL was rushed and was never thought through 
properly. He envisioned something like an interpreted PL/I. In other 
words a fully featured imperative language that could do much more than 
just schedule programs.


I was lucky enough to work for a shop that were running different 
platforms and cross-trained sysprogs to support them all - MVS, AS/400 
and AIX. I was and am still impressed by AS/400. When you scrutinize CL 
it seems to be what Brooks always wanted from JCL. Look how easy it is 
to convert a spool file to HTML on i series 
http://search400.techtarget.com/news/556555/CL-Source-Code.



It has to do with variable substitution occurring as interpretation time. How 
would you get out of a loop except by using the CC? �Except in extreme cases, 
would running the same program multiple times without a JCL change really do 
something useful.


Surely an extension to JCL to support looping would include test conditions
(perhaps on values of JCL symbols) other than CC.


As for complaining about JCL EXEC statement being first is unnatural, I have to 
laugh.


Please laugh.  I think a couple of us were engaging in hyperbole; even as
when I called IEBGENER intuitive.

-- 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: Aging Sysprogs = Aging Farmers

2013-11-07 Thread Joel C. Ewing

On 11/06/2013 09:56 AM, Kirk Talman wrote:
 IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 
 11/06/2013 10:32:09 AM:
 
 From: Paul Gilmartin paulgboul...@aim.com
 
 The reverse logic of condition codes probably was intuitive to an
 assembler or FORTRAN programmer who thought of branching
 around a statement.
 
 I remember first seeing CCs in 1966 while in graduate school in physics 
 and thinking that somewhere there was a mathematician who understood this, 
 but humans would never.  My opinion has not changed in 47 years.  A 
 virtual beer to whoever thought up the JCL IF statement.
 

As a former Assembler and FORTRAN programmer (and one with a mathematics
background), I can assert that COND was definitely not intuitive to us
either.  To me, a JCL keyword named COND should have implied the
conditions under which the step is executed.  If they wanted it to be
the conditions causing the step to be skipped a different name should
have been chosen, like SKIPIF.  And then of course the relational
expression in COND is backwards.  A normal person wanting to know if a
prior CC was greater than 8 would never use reverse-think and require
the question be asked as whether 8 was less than the prior CC.

COND has always looked to me like a feature added as an after thought,
with the implementors choosing the syntax for their convenience, not
something designed with the user in mind.

I share your celebration of the IF Statement; although I have been bit
on one occasion by a non-intuitive behavior of IF statements as well:
the first EXEC in a JOB is always unconditionally executed no matter
what (which precludes using SET symbols and a leading IF to control
selective skipping of the first step, which seems a reasonable thing to
try just based on syntax)

-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: Aging Sysprogs = Aging Farmers

2013-11-07 Thread Farley, Peter x23353

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Joel C. Ewing
Sent: Thursday, November 07, 2013 11:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Aging Sysprogs = Aging Farmers
Snipped
I share your celebration of the IF Statement; although I have been bit
on one occasion by a non-intuitive behavior of IF statements as well:
the first EXEC in a JOB is always unconditionally executed no matter
what (which precludes using SET symbols and a leading IF to control
selective skipping of the first step, which seems a reasonable thing to
try just based on syntax)

Which is easily resolved by always using a first step of PGM=IEFBR14.  In 
many production JCL standards, the first step must always be the scheduler 
package startup routine anyway (e.g., CA11) which must execute to keep the 
scheduler in control, so the problem (almost) never occurs in a production 
JCL.

Peter

-- 

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: JCL (was: Re: Aging Sysprogs = Aging Farmers)

2013-11-07 Thread Ze'ev Atlas

Let me add another complains about JCL, it allows changing source code meaning 
in run time and sometimes this is hairy:

//XXX DD DSN=
//  DCB=(LRECL=80,R
//...

The above is legit although I would fire anybody who doed it.  R could be 
resolved to:
// EXEC YYY,R='BLKSIZE=8000)'   

or it could be resolved to an early example of cose injection of your choice

ZA

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

Re: Aging Sysprogs = Aging Farmers

2013-11-07 Thread Ted MacNEIL

grep stands for General Regular Expression

I had always thought it was:
Get Regular Expression and Print
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

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

Re: Aging Sysprogs = Aging Farmers

2013-11-07 Thread John McKown

perhaps the book I read got it wrong. Or I misunderstood (likely). I don't
have a true UNIX background. Mainly what I've picked up by being a Linux
fan-boy.


On Thu, Nov 7, 2013 at 11:01 AM, Ted MacNEIL eamacn...@yahoo.ca wrote:

 grep stands for General Regular Expression

 I had always thought it was:
 Get Regular Expression and Print
 -
 Ted MacNEIL
 eamacn...@yahoo.ca
 Twitter: @TedMacNEIL

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




-- 
This is clearly another case of too many mad scientists, and not enough
hunchbacks.

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: JCL (was: Re: Aging Sysprogs = Aging Farmers)

2013-11-07 Thread Mitch

Ze'ev,

I work with a product that would prevent this type of thing from happening.  
JCL that does not meet site requirements would never make it into production.  
It can also optionally be prevented from being added to the production batch 
schedule, if so desired.

Regards,


Mitch McCluhan,
Legacy Modernization Consultant
www.lcmg.us



-Original Message-
From: Ze'ev Atlas zatl...@yahoo.com
To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU
Sent: Thu, Nov 7, 2013 8:39 am
Subject: Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)


Let me add another complains about JCL, it allows changing source code meaning 
n run time and sometimes this is hairy:
//XXX DD DSN=
/  DCB=(LRECL=80,R
/...
The above is legit although I would fire anybody who doed it.  R could be 
esolved to:
/ EXEC YYY,R='BLKSIZE=8000)'   
or it could be resolved to an early example of cose injection of your choice
ZA
--
or IBM-MAIN subscribe / signoff / archive access instructions,
end 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: JCL (was: Re: Aging Sysprogs = Aging Farmers)

2013-11-07 Thread Richard Pinion

And to throw another twist to this thread, some people say the LRECL and RECFM 
should not be coded in the JCL.  That way when a change is made to the program 
source, that affects LRECL and/or RECFM, the corresponding JCL doesn't have to 
be updated.  What are some opinions about that methodology?



--- mitc...@aol.com wrote:

From: Mitch mitc...@aol.com
To:   IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)
Date: Thu, 7 Nov 2013 12:34:39 -0500

Ze'ev,

I work with a product that would prevent this type of thing from happening.  
JCL that does not meet site requirements would never make it into production.  
It can also optionally be prevented from being added to the production batch 
schedule, if so desired.

Regards,


Mitch McCluhan,
Legacy Modernization Consultant
www.lcmg.us



-Original Message-
From: Ze'ev Atlas zatl...@yahoo.com
To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU
Sent: Thu, Nov 7, 2013 8:39 am
Subject: Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)


Let me add another complains about JCL, it allows changing source code meaning 
n run time and sometimes this is hairy:
//XXX DD DSN=
/  DCB=(LRECL=80,R
/...
The above is legit although I would fire anybody who doed it.  R could be 
esolved to:
/ EXEC YYY,R='BLKSIZE=8000)'   
or it could be resolved to an early example of cose injection of your choice
ZA
--
or IBM-MAIN subscribe / signoff / archive access instructions,
end 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




_
Netscape.  Just the Net You Need.

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

Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)

2013-11-07 Thread Gerhard Postpischil


On 11/7/2013 12:41 PM, Richard Pinion wrote:

And to throw another twist to this thread, some people say the LRECL
and RECFM should not be coded in the JCL.  That way when a change is
made to the program source, that affects LRECL and/or RECFM, the
corresponding JCL doesn't have to be updated.  What are some opinions
about that methodology?


DCB parameters should never be required for input files. An output block 
size should be used only in special situations (e.g., transfer to 
another system). For output files, I prefer to leave the attributes to 
the DCB exit, allowing me to route print to a PDS without destroying it 
(and the program/subroutine handles padding). What I detest are programs 
where nothing is specified, and there are no defaults, requiring 
explicit DCB parameters on each statement.


I'm unhappy about the utilities, and sloppy CoBOL, forcing the DCB 
parameters thus requiring an extra step to copy the output someplace 
else with appropriate padding and carriage control conversion. I wish 
that IBM had provided a single output routine for the utilities, and 
made it generally available as a subroutine. (Ditto with writing messages)


Gerhard Postpischil
Bradford, Vermont

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

Re: Aging Sysprogs = Aging Farmers

2013-11-07 Thread John Gilmore

I don't think the etiology of an acronym matters much or for long.
COBOL is an acronym for Common Business Oriented Language, but who
cares.

Indeed, it is often better not to look under the hood/bonnet.  Consider

GRS
Global Resource Serialization
Gamma Ray Spectrometer
Gender Reassignment Surgery

DCBE
Data Control Block Extension
Double Contrast Barium Enema

DASD
Direct Access Storage Device
Deputy Assistant Secretary of Defense
Diploma in the Art of Spiritual Direction

etc., etc., ad nauseam.  Even the structured ones like BSAM and QSAM
can be problematic.  One of my teenagers, making what she described as
a 'plausible inference' from the existence of this pair and that of
BDAM, asked me, with guile, about the properties of QDAM.

John Gilmore, Ashland, MA 01721 - USA

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

Re: Aging Sysprogs = Aging Farmers

2013-11-07 Thread David L. Craig

On 13Nov07:1701+, Ted MacNEIL wrote:

 grep stands for General Regular Expression
 
 I had always thought it was:
 Get Regular Expression and Print

No, it means global, the ed command followed by a regular
expression and a command to perform upon the set of lines
matched by said regex; e.g., g/^$/d will delete all null
lines in the file.  After a while the Fathers wearied of
firing up ed when all they wanted to do was extract a
subset of a text file.  In case it is not obvious, the
verb was coined before the executable was envisioned.
-- 
not cent from sell
May the LORD God bless you exceedingly abundantly!

Dave_Craig__
So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe.
__--from_Nightfall_by_Asimov/Silverberg_

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

Re: Aging Sysprogs = Aging Farmers

2013-11-07 Thread zMan

I've read that the true origin of grep is lost in the mists of time; I've
also seen Global [on a] Regular Expression [and] Print.

It may not be important on some level, but it's interesting and fun!


On Thu, Nov 7, 2013 at 12:01 PM, Ted MacNEIL eamacn...@yahoo.ca wrote:

 grep stands for General Regular Expression

 I had always thought it was:
 Get Regular Expression and Print
 -
 Ted MacNEIL
 eamacn...@yahoo.ca
 Twitter: @TedMacNEIL

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




-- 
zMan -- I've got a mainframe and I'm not afraid to use it

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

Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)

On Thu, 7 Nov 2013 09:41:40 -0800, Richard Pinion wrote:

And to throw another twist to this thread, some people say the LRECL and RECFM 
should not be coded in the JCL.  That way when a change is made to the program 
source, that affects LRECL and/or RECFM, the corresponding JCL doesn't have to 
be updated.  What are some opinions about that methodology?

If by changing the program source you mean coding LRECL and RECFM in the
DCB, the JCL needn't be changed.  Values coded in the DCB quietly override
any coded in JCL.  Shouldn't a warning of such disagreement be issued?
I believe so, but via what channel?


-Original Message-
From: Ze'ev Atlas
Sent: Thu, Nov 7, 2013 8:39 am

Let me add another complains about JCL, it allows changing source code meaning
n run time and sometimes this is hairy:
//XXX DD DSN=
/  DCB=(LRECL=80,R
/...
The above is legit although I would fire anybody who doed it.  R could be
esolved to:
/ EXEC YYY,R='BLKSIZE=8000)'
or it could be resolved to an early example of cose injection of your choice

I applaud languages such as Rexx in which lexical metacharacters are
never recognized in text introduced by variable substitution.  Rexx
provides a workaround in the ever-so-controversial INTERPRET instruction.

My first mentor in JCL had a habit disabling options by defaulting
a PROC parameter to ' ' and enabling them by substituting ''.
E.g.:

FOO  PROC  C=' '  (set C='' to bypass step!)
SEXEC  PGM=WOMBATC,COND=(0,LE)
 PEND

(Now you know how I got to be the way I am.)

-- gil

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

Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)

2013-11-07 Thread Tony Harminc

On 7 November 2013 12:41, Richard Pinion rpin...@netscape.com wrote:
 And to throw another twist to this thread, some people say the LRECL and 
 RECFM should not be coded in the JCL.  That way when a change is made to the 
 program source, that affects LRECL and/or RECFM, the corresponding JCL 
 doesn't have to be updated.  What are some opinions about that methodology?

Taking that to the extreme one could say that nothing should be coded
on DD statements, i.e. that programs should deal with DSNAMEs rather
then the intermediary of DDNAMEs. Which is indeed how most non-z/OS
systems work. The late binding provided by DD statements is one of the
strongest, if clumsiest, things about OS/360 and its descendants. Why
should this not apply to LRECL, RECFM, and the other DCB parameters as
much as anything else?

Tony H.

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

Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)

2013-11-07 Thread Mitch

Paul (et al):

As I have been alluding to, I work with a product that can do all of what has 
been discussed here, or any flavor of it.  It can be invoked in a variety of 
ways, from direct calls, to part of an automated change management process, to 
flagging JCL at submission time to error notification when a schedule is built, 
to actually capturing the JCL as it is being written to the scheduler and 
changed (with the appropriate notifications made) so that the production batch 
environment NEVER fails with these types of conditions.

Regards,

Mitch McCluhan,
Legacy Modernization Consultant
www.lcmg.us



-Original Message-
From: Paul Gilmartin paulgboul...@aim.com
To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU
Sent: Thu, Nov 7, 2013 10:23 am
Subject: Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)


On Thu, 7 Nov 2013 09:41:40 -0800, Richard Pinion wrote:
And to throw another twist to this thread, some people say the LRECL and RECFM 
hould not be coded in the JCL.  That way when a change is made to the program 
ource, that affects LRECL and/or RECFM, the corresponding JCL doesn't have to 
e updated.  What are some opinions about that methodology?

f by changing the program source you mean coding LRECL and RECFM in the
CB, the JCL needn't be changed.  Values coded in the DCB quietly override
ny coded in JCL.  Shouldn't a warning of such disagreement be issued?
 believe so, but via what channel?

-Original Message-
From: Ze'ev Atlas
Sent: Thu, Nov 7, 2013 8:39 am

Let me add another complains about JCL, it allows changing source code meaning
n run time and sometimes this is hairy:
//XXX DD DSN=
/  DCB=(LRECL=80,R
/...
The above is legit although I would fire anybody who doed it.  R could be
esolved to:
/ EXEC YYY,R='BLKSIZE=8000)'
or it could be resolved to an early example of cose injection of your choice

 applaud languages such as Rexx in which lexical metacharacters are
ever recognized in text introduced by variable substitution.  Rexx
rovides a workaround in the ever-so-controversial INTERPRET instruction.
My first mentor in JCL had a habit disabling options by defaulting
 PROC parameter to ' ' and enabling them by substituting ''.
.g.:
FOO  PROC  C=' '  (set C='' to bypass step!)
EXEC  PGM=WOMBATC,COND=(0,LE)
PEND
(Now you know how I got to be the way I am.)
-- gil
--
or IBM-MAIN subscribe / signoff / archive access instructions,
end 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: IF (was: Aging ...)

2013-11-07 Thread Mitch

Paul (et al):

Again, I have an answer for all of you.  BTW, it is also available directly 
from IBM.

Regards,

Mitch



-Original Message-
From: Paul Gilmartin paulgboul...@aim.com
To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU
Sent: Thu, Nov 7, 2013 10:04 am
Subject: IF (was: Aging ...)


On Thu, 7 Nov 2013 10:06:14 -0600, Joel C. Ewing wrote:

I share your celebration of the IF Statement; although I have been bit
on one occasion by a non-intuitive behavior of IF statements as well:
the first EXEC in a JOB is always unconditionally executed no matter
what (which precludes using SET symbols and a leading IF to control
selective skipping of the first step, which seems a reasonable thing to
try just based on syntax)
 
 suspect that IF piggybacks on the implementation of COND.
f I put on my mathematician's hat I can say that the behavior
f COND is logical (as opposed to intuitive).  It means, skip
he current step the set of prior steps satisfying the predicate
s nonempty.  Of course that set is empty for the first step,
ven when I code, as is my custom, COND=(0,LE) to skip
 step unconditionally.  That argument can not be made for IF.
The JCL Ref states in Placement in the JCL  (from memory)
hat IF must (should?) not appear before the first EXEC
tatement.  Dammit!  Such assertions should be imperative,
ot advisory, and their transgressions should be reported
s syntax errors.  Likewise, I can code IF ( FALSE ) THEN
hich does not match any syntax documented as valid, but
o syntax error is reported.  (It results in skipping any step
ut the first in the job.)  The JCL Ref states that any form
f the IF predicate not documented as not valid may produce
npredictable and subject-to-change results even though
t may appear to work in a particular instance.  Dammit again!
yntax errors should be reported.  This sort of thing makes
e a strong adversary of Postel's Robustness Principle.
I have ranted about this previously here, in response to
hich an IBM weasel defended the behavior, noting that
here are many cases in which undocumented syntax is
ot reported as errors because the constructs are reserved
ither for IBM internal use or for future enhancements.
is example was undocumented parameters to library
acros.  This is radically different.  I suspect, rather, that
 rogue new-grad coder, enamored of BNF syntax and
ecursive descent parsers, coded the parser as he believed
t should be, not as it was specified.  The deviation was
ot discovered in testing (not enough error paths exercised)
nd/or resource constraints precluded emendation.
I have another dissatisfaction with IF ...  The labels on
orresponding IF, ELSE, and ENDIF should be required to
atch, with mismatches reported as syntax errors, to
acilitate verification of nesting.  Rather, the JCL Ref
tates that those labels should (IIRC) be unique.  Again,
ransgressions are not reported.
-- gil
--
or IBM-MAIN subscribe / signoff / archive access instructions,
end 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: JCL (was: Re: Aging Sysprogs = Aging Farmers)

2013-11-07 Thread Martin Packer

Doing that would make the JCL poor (or apparently contradictory) 
documentation. So I would hope the disagreement would be flagged somehow.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, 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:   Paul Gilmartin paulgboul...@aim.com
To: IBM-MAIN@listserv.ua.edu
Date:   07/11/2013 18:23
Subject:Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)
Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu



On Thu, 7 Nov 2013 09:41:40 -0800, Richard Pinion wrote:

And to throw another twist to this thread, some people say the LRECL and 
RECFM should not be coded in the JCL.  That way when a change is made to 
the program source, that affects LRECL and/or RECFM, the corresponding JCL 
doesn't have to be updated.  What are some opinions about that 
methodology?

If by changing the program source you mean coding LRECL and RECFM in the
DCB, the JCL needn't be changed.  Values coded in the DCB quietly override
any coded in JCL.  Shouldn't a warning of such disagreement be issued?
I believe so, but via what channel?


-Original Message-
From: Ze'ev Atlas
Sent: Thu, Nov 7, 2013 8:39 am

Let me add another complains about JCL, it allows changing source code 
meaning
n run time and sometimes this is hairy:
//XXX DD DSN=
/  DCB=(LRECL=80,R
/...
The above is legit although I would fire anybody who doed it.  R could be
esolved to:
/ EXEC YYY,R='BLKSIZE=8000)'
or it could be resolved to an early example of cose injection of your 
choice

I applaud languages such as Rexx in which lexical metacharacters are
never recognized in text introduced by variable substitution.  Rexx
provides a workaround in the ever-so-controversial INTERPRET instruction.

My first mentor in JCL had a habit disabling options by defaulting
a PROC parameter to ' ' and enabling them by substituting ''.
E.g.:

FOO  PROC  C=' '  (set C='' to bypass step!)
SEXEC  PGM=WOMBATC,COND=(0,LE)
 PEND

(Now you know how I got to be the way I am.)

-- gil

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

Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)

On Thu, 7 Nov 2013 13:37:54 -0500, Tony Harminc wrote:

Taking that to the extreme one could say that nothing should be coded
on DD statements, i.e. that programs should deal with DSNAMEs rather
then the intermediary of DDNAMEs. Which is indeed how most non-z/OS
systems work.

In UNIX, I see the analogue of DDNAME as the descriptor.  If a program
insists on writing to stdout (descriptor 1, analogous to SYSTERM), I can
redirect with:

program 1logfile

And, this handled correctly (IMO) by the kernel.  The subject program
needn't process, nor even be aware of, the redirection, in sharp contrast
to the handling of the alternate DDNAME list in OS.  So, I'll take the
view quite opposite to yours.  If the program looks for copybooks
in SYS1.MACLIB, that's an undesirable early binding; if it looks in SYSLIB
that's a preferable late binding that can be deferred until the programmer
codes the JCL.

When I said a couple weeks ago that alternate DDNAMES should be
handled by ATTACH, transparent to the application, someone asked,
What about programs that scan the TIOT for specific DDNAMEs?
Alas, that's a relic of the early resource-constrained implementation
of OS.  The requirement for applications to access system control
blocks should be minimized in favor of APIs to obtain their content.
If this had been done, moving the TIOT above the bar (very hypothetical
example) would not impact existing application programs.

... The late binding provided by DD statements is one of the
strongest, if clumsiest, things about OS/360 and its descendants. Why
should this not apply to LRECL, RECFM, and the other DCB parameters as
much as anything else?

Some HLL runtime libraries can readily deal with diverse RECFMs for a
given DDNAME, even transparently to the application code.  Most
assembler programs are not coded that way.  (Ed J. might jump in
with exceptions.)

-- gil

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

Re: Aging Sysprogs = Aging Farmers

2013-11-07 Thread Jon Perryman

I don't see acronyms in different industries a problem. The ones that get me 
are within IBM's own website. I can't remember specific's. More than once, I 
read something that used a well known z/OS acronym. Very confusing until you 
realize it's the same acronym but from a different area. 

Jon Perryman



 From: John Gilmore jwgli...@gmail.com



I don't think the etiology of an acronym matters much or for long.
COBOL is an acronym for Common Business Oriented Language, but who
cares.

Indeed, it is often better not to look under the hood/bonnet.  Consider

GRS
Global Resource Serialization
Gamma Ray Spectrometer
Gender Reassignment Surgery

DCBE
Data Control Block Extension
Double Contrast Barium Enema

DASD
Direct Access Storage Device
Deputy Assistant Secretary of Defense
Diploma in the Art of Spiritual Direction

etc., etc., ad nauseam.  Even the structured ones like BSAM and QSAM
can be problematic.  One of my teenagers, making what she described as
a 'plausible inference' from the existence of this pair and that of
BDAM, asked me, with guile, about the properties of QDAM.

John Gilmore, Ashland, MA 01721 - USA

--
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: Aging Sysprogs = Aging Farmers

2013-11-07 Thread Mike Schwab

On Thu, Nov 7, 2013 at 12:15 PM, John Gilmore jwgli...@gmail.com wrote:
deleted
 DASD
deleted
 Diploma in the Art of Spiritual Direction
deleted
Doctor in the Art of Spirit Detention?

Who you gonna call?
-- 
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

Re: Aging Sysprogs = Aging Farmers

2013-11-07 Thread Gerhard Postpischil


On 11/7/2013 1:27 PM, Paul Gilmartin wrote:

etc., etc., ad nauseam.  Even the structured ones like BSAM and QSAM
can be problematic.  One of my teenagers, making what she described as
a 'plausible inference' from the existence of this pair and that of
BDAM, asked me, with guile, about the properties of QDAM.


That doesn't make sense.  Rather, I anticipate breathlessly the advent
of QPAM.  Please!


I doubt that QDAM would have made much sense in the sixties, and even 
less these days. QSAM provides advantages due to buffering, and it's not 
clear that there is much use for sequential access in BDAM files. 
Although I can see a benefit to hybrid processing, similar to VSAM's 
sequential vs. random modes. In the rare cases that BDAM requires 
sequential processing, the user is free to use BSAM or QSAM.


QPAM on the other hand would be more likely to provide benefits, and the 
functionality is fairly easy for even a neophyte to implement using two 
DCBs.


Gerhard Postpischil
Bradford, Vermont

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

Re: Aging Sysprogs = Aging Farmers

2013-11-07 Thread John Gilmore

I refrained from doing that, confining myself to what others had
written several times.  Once one decides to give one's own imagination
free range, . . .

O, that way madness lies; let me shun that;
No more of that.


John Gilmore, Ashland, MA 01721 - USA

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

Re: Aging Sysprogs = Aging Farmers

2013-11-07 Thread John Gilmore

About QDAM, I should perhaps have made it clearer that my student was
having me on.

John Gilmore, Ashland, MA 01721 - USA

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

Re: Aging Sysprogs = Aging Farmers

In
off17b8bda.726774d6-on86257c1b.0052b967-86257c1b.0052c...@bluecrossmn.com,
on 11/06/2013
   at 09:04 AM, Alan Field alan_c_fi...@bluecrossmn.com said:

Simply from option 6 I entered SMCOPY

That's equivalent to SMCOPY FROMSTREAM(TSOOUT) PRINT(A); why would you
expect it to work without Session Manager? Try it with FROMDATASET and
TODATASET.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Aging Sysprogs = Aging Farmers

In 8296119609469576.wa.paulgboulderaim@listserv.ua.edu, on
11/06/2013
   at 09:32 AM, Paul Gilmartin paulgboul...@aim.com said:

The reverse logic of condition codes probably was intuitive to 
an assembler or FORTRAN programmer who thought of branching 
around a statement.

This assembler programmer never found COND to be intuitive, nor the
default for SPACE. OTOH, lots of other things in JCL seemed and still
seem reasonable.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Aging Sysprogs = Aging Farmers

In 9693709159318087.wa.paulgboulderaim@listserv.ua.edu, on
11/06/2013
   at 09:35 AM, Paul Gilmartin paulgboul...@aim.com said:

Is that separately priced?

SM was separately priced long ago in a galaxy far away; it's included
in TSO/E. You do, however, need a separate logon proc.

Does it play well with ISPF?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Aging Sysprogs = Aging Farmers

In
CAArMM9RJk=emmpr7mks0cmaooupudokrqtksc2mtwjhar0r...@mail.gmail.com,
on 11/06/2013
   at 12:03 PM, Tony Harminc t...@harminc.net said:

It's surely TSO parse (IKJPARS) that hasn't been updated.

Shirley not. PARSE handles path names just fine. The problem is that
IBM decided to keep dsname and path name separate, and you seem to
have some sympathy for that separation.

SMCOPY should have a
different keyword, perhaps PATH, for files.

That would be a change to SMCOPY, not a change to PARSE.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Aging Sysprogs = Aging Farmers

In 4716870597662583.wa.paulgboulderaim@listserv.ua.edu, on
11/06/2013
   at 11:47 AM, Paul Gilmartin paulgboul...@aim.com said:

Were we talking about that, or about the IDCAMS REPRO subcommand?

We were talking about the TSO REPRO command, which invokes IDCAMS. It
has nothing to do with the assembler pseudo-op of the same name,
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Aging Sysprogs = Aging Farmers

In 6730883549051769.wa.paulgboulderaim@listserv.ua.edu, on
11/06/2013
   at 09:45 AM, Paul Gilmartin paulgboul...@aim.com said:

What's a data set?

Anything that can be allocated to a ddname.

What's not a data set?

Anything else, e.g., an SM stream.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Aging Sysprogs = Aging Farmers

In 1383756905.52974.yahoomail...@web181001.mail.ne1.yahoo.com, on
11/06/2013
   at 08:55 AM, Jon Perryman jperr...@pacbell.net said:

I mostly used CL/Supersession so I don't know the specifics for
Session Manager.

Apples and oranges. The SM in TSO/E manages I/O for a single session.
It does not multiplex a terminal for multiple sessions.

Session manager allowed multiple terminal sessions from a single
terminal.

There are programs that allow that, but TSO Session Manager isn't one
of them. It manages a single session; more specifically, it manages
the screen for the line mode I/O in a single session.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Aging Sysprogs = Aging Farmers

In 7069148599028647.wa.paulgboulderaim@listserv.ua.edu, on
11/06/2013
   at 12:16 PM, Paul Gilmartin paulgboul...@aim.com said:

But the (GNU, not POSIX) less is a facetious counterderivation from
(POSIX) more,

Water is wet. The point is that the Eunix g command names are
cryptic, as are other aspects. It's the best OS ever developed for the
PDP-7.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Aging Sysprogs = Aging Farmers

In 292913362407.wa.paulgboulderaim@listserv.ua.edu, on
11/06/2013
   at 11:44 AM, Paul Gilmartin paulgboul...@aim.com said:

Past tense?  Is it gone?  STTL?

No. However, TSO Session Manager is oriented towards improving the
productivity of users invoking line mode applications, and these days
most TSO work is under ISPF.

Multiple sessions with the same user ID?  On the same LPAR?

From, e.g., TPX, yes. But not multiple TSO sessions on the same LPAR
with the same userid, and not via TSO SM.

And concerning COPY, wasn't it mentioned earlier here that it
belonged to a separately priced feature, perhaps now withdrawn?

COPY belongs to TSO Data Set Utilities, out of support for decades.
Neither REPRO nor SMCOPY is part of a separately priced component.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Aging Sysprogs = Aging Farmers

In 9722190132556452.wa.paulgboulderaim@listserv.ua.edu, on
11/06/2013
   at 12:22 PM, Paul Gilmartin paulgboul...@aim.com said:

But why didn't they follow the same direction naming library 
macros?

No standards czar.

And why isn't STIMER named WAIT,

Why use the name WAIT for a macro that doesn't wait?

   2.  If no exit routine address is specified, there is no
   indication of completion except when WAIT is specified.

 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Aging Sysprogs = Aging Farmers

In 20131106211556.79f3c24...@panix5.panix.com, on 11/06/2013
   at 04:15 PM, Rich Greenberg ric...@panix.com said:

On the mass storage of the time (i.e.  paper tape),

The mass storage of the time was magnetic strips, e.g., C.R.A.M,
noodle picker, R.A.C.E. For smaller files there were disks and drums.
Eunix g did not run from paper tape.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Aging Sysprogs = Aging Farmers

In 1383778968.24982.yahoomail...@web141706.mail.bf1.yahoo.com, on
11/06/2013
   at 03:02 PM, Frank Swarbrick frank.swarbr...@yahoo.com said:

Does anyone actually run X-Windows on z/OS? 

pedantNo./pedant
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Aging Sysprogs = Aging Farmers

In 3096893122923586.wa.paulgboulderaim@listserv.ua.edu, on
11/06/2013
   at 05:48 PM, Paul Gilmartin paulgboul...@aim.com said:

I was never acquainted with anything slower than the Teletype 33, 

Even the lowly 28 ran at 75 baud. I suspect that Rich Greenberg was
seeing 60 wpm, not 60 cpm.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Aging Sysprogs = Aging Farmers and other mind wanderings....

In 014f01cedb5e$ca0dbdb0$5e293910$@soundsoftware.us, on 11/06/2013
   at 06:12 PM, Duffy Nightingale, SSPI du...@soundsoftware.us
said:

That sounds pretty cool.  Is the mainframe server code you are
talking about applications or something else?  Not to enrage the
assembler bigots on here, after all, I am one but COBOL seems to 
be the simplest, easy to read, easy to teach programming language 
I have ever seen.

Have they removed the booby traps. Are they still using 77 and 88 as
magic numbers?

Why would you not use COBOL for apps? 

Because it's an awkward language, although not as bad as it used to
be.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Aging Sysprogs = Aging Farmers

In 527b17ad.2060...@valley.net, on 11/06/2013
   at 11:31 PM, Gerhard Postpischil gerh...@valley.net said:

The first interactive terminal I used was an IBM 1050, running at 
145  bps

134.5?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)

2013-11-07 Thread Clark Morris

On 7 Nov 2013 10:38:24 -0800, in bit.listserv.ibm-main you wrote:

On 7 November 2013 12:41, Richard Pinion rpin...@netscape.com wrote:
 And to throw another twist to this thread, some people say the LRECL and 
 RECFM should not be coded in the JCL.  That way when a change is made to the 
 program source, that affects LRECL and/or RECFM, the corresponding JCL 
 doesn't have to be updated.  What are some opinions about that methodology?

Taking that to the extreme one could say that nothing should be coded
on DD statements, i.e. that programs should deal with DSNAMEs rather
then the intermediary of DDNAMEs. Which is indeed how most non-z/OS
systems work. The late binding provided by DD statements is one of the
strongest, if clumsiest, things about OS/360 and its descendants. Why
should this not apply to LRECL, RECFM, and the other DCB parameters as
much as anything else?

I worked with at least 1 Unix shell that allowed the specification of
file name to be in the batch script.  Those who know UNIX/LINUX are
better able to describe how this is done.

Clark Morris

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

Re: IF (was: Aging ...)

In 3903137801243154.wa.paulgboulderaim@listserv.ua.edu, on
11/07/2013
   at 12:04 PM, Paul Gilmartin paulgboul...@aim.com said:

I suspect that IF piggybacks on the implementation of COND. If I 
put on my mathematician's hat I can say that the behavior of COND 
is logical (as opposed to intuitive).

If I put on *my* mathematicians hat then I must say that the COND
notation is clumsy and unnatural. Logical doesn't apply to
nomenclature.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Aging Sysprogs = Aging Farmers

On Wed, 6 Nov 2013 16:51:03 -0500, Shmuel Metz (Seymour J.) wrote:

What's a data set?

Anything that can be allocated to a ddname.
 
As I said, I have attempted to invoke that definition (pretty directly
from Using Data Sets) when IBM Tech Support has told me, But the
Ref says that DDNAME must refer to a data set.  (Tautology?)  I've
never won the argument.  I don't recall that I've ever got even a DOC
APAR for a clarification.

What's not a data set?

Anything else, e.g., an SM stream.

Or, in the view of IBM Tech Support for some products, a UNIX file.

-- gil

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

Re: Aging Sysprogs = Aging Farmers

2013-11-07 Thread Jon Perryman

This response feels like we're playing a game of Jeopardy (Alex, I'll take 
datasets for $100). Did you actually contact IBM to ask them what is a 
dataset?

Did it have something to do with specifying a Unix file name in a DSN 
parameter?  If so, then the answer is that not all datasets have a dataset 
name. UNIX datasets have a file name (no DSN). SYSOUT datasets have SYSOUT 
attributes (no DSN). Subsystem datasets have subsystem information (no DSN). 
DSF and DFDSS use entire volumes as datasets which doesn't have a DSN for the 
DD.

Can you give us some context? Why is this important or even relavent?

Jon Perryman. 




 From: Paul Gilmartin paulgboul...@aim.com


On Wed, 6 Nov 2013 16:51:03 -0500, Shmuel Metz (Seymour J.) wrote:

What's a data set?

Anything that can be allocated to a ddname.
 
As I said, I have attempted to invoke that definition (pretty directly
from Using Data Sets) when IBM Tech Support has told me, But the
Ref says that DDNAME must refer to a data set.  (Tautology?)  I've
never won the argument.  I don't recall that I've ever got even a DOC
APAR for a clarification.

What's not a data set?

Anything else, e.g., an SM stream.

Or, in the view of IBM Tech Support for some products, a UNIX file.

-- 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: Aging Sysprogs = Aging Farmers

On 2013-11-07 19:11, Jon Perryman wrote:
 This response feels like we're playing a game of Jeopardy (Alex, I'll take 
 datasets for $100). Did you actually contact IBM to ask them what is a 
 dataset?
 
In other words, should I ask them whether the information in
Using Data Sets is correct?

 Did it have something to do with specifying a Unix file name in a DSN 
 parameter?

No.  Do you not trust me to know better than that?

If so, then the answer is that not all datasets have a dataset name. UNIX 
datasets have a file name (no DSN). SYSOUT datasets have SYSOUT attributes (no 
DSN). Subsystem datasets have subsystem information (no DSN). DSF and DFDSS use 
entire volumes as datasets which doesn't have a DSN for the DD.
 
 Can you give us some context? Why is this important or even relavent?
 
AMATERSE.  I, like many others, find it easier to FTP a
TERSEd archive to my desktop than to the z.  And I have
a directory NFS mounted to both the desktop and the z.  So:

//* SET PATH redacted.
//  SET ATTRS='RECFM=FB,LRECL=1024,BLKSIZE=30720'
//*
//* =
//UNPACK   PROC
//*
//UNP  EXEC  PGM=AMATERSE,PARM=UNPACK
//SYSPRINT  DD SYSOUT=(,)
//SYSUT2DD UNIT=SYSALLDA,SPACE=(1000,1000)
//*
// PEND
//* =
//* UNIX file only!
//*
//TESTCEXEC  UNPACK
//*
//SYSUT1DD   PATHOPTS=ORDONLY,PATH='PATH',ATTRS

... fails with:

* TOP OF DATA 
***
** AMA572I STARTING TERSE DECODE   UNPACK   20:08:51  11/07/2013 
** AMA527I  INPUT  - DDNAME : SYSUT1   DSNAME: ...PATH=.SPECIFIED...
** AMA583E  INPUT DEVICE TYPE IS UNSUPPORTED
** AMA573I TERSE COMPLETE DECODE   UNPACK   20:08:51  11/07/2013 
** AMA504I  RETURN CODE: 32
 BOTTOM OF DATA 
*

Ironically, this:

//* =
//* Temporary DS followed by UNIX file!
//*
//TESTBEXEC  UNPACK
//SYSUT1DD   UNIT=SYSALLDA,SPACE=(1,0),ATTRS,DSORG=PS
//  DD   PATHOPTS=ORDONLY,PATH='PATH',ATTRS
//*
//* =

... succeeds:

* TOP OF DATA 
***
** AMA572I STARTING TERSE DECODE   UNPACK   20:08:50  11/07/2013 
** AMA527I  INPUT  - DDNAME : SYSUT1   DSNAME: 
SYS13311.T200847.RA000.TERSEHFS.R0165256
** AMA528I  OUTPUT - DDNAME : SYSUT2   DSNAME: 
SYS13311.T200847.RA000.TERSEHFS.R0165255
** AMA555I  THE VALUES ARE:  BLKSIZE= 3120LRECL=80  PACKTYPE=SPACK   
RECFM=FIXED
** AMA583I  INPUT DATASET SIZE IN BYTES: 4096 OUTPUT DATASET SIZE IN BYTES: 
15360 COMPRESSION RATIO: 26%
** AMA573I TERSE COMPLETE DECODE   UNPACK   20:08:50  11/07/2013 
** AMA504I  RETURN CODE: 0
 BOTTOM OF DATA 
*

The access method is quite capable of reading the UNIX file; merely
AMATERSE hates UNIX and refuses to deal with it, but isn't smart
enough to look beyond the first catenand.

I haven't reported this specific case; I've come to expect, and become
weary of IBM's stock answer; some form of WAD; that's not a data set.

The design is wrong: rather than anticipating an error that will
never occur, the utility should simply OPEN and READ/GET, passing
on any errors reported by the access method.

-- gil

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

Re: Aging Sysprogs = Aging Farmers

2013-11-07 Thread Jon Perryman

Not all datasets are created equal. E.g. DCB and VSAM don't work together. E.g. 
IEBGENER doesn't support VSAM. I suspect that AMATERSE won't either. So the 
answer is these dataset types are not supported by AMATERSE which truly is WAD. 
UNIX or VSAM file support would be a new feature request (no fix required). The 
message displayed is incorrect so you could request a fix for that (it says 
unsupported device instead of unsupported dataset organization).


I've never read USING DATA SETS so I can't tell you whether it's correct.  
IBM support telling you that Unix files are not datasets sounds like an error 
on their part but who among has never made a mistake. Regardless, the correct 
answer to your problem will still result in WAD. .

As for concatenating an MVS dataset before the UNIX file isn't as ironic as it 
seem's. This actually occurs more often than you think. The classic example is 
specifying a block size on the first dataset that is larger than it's block 
size. That is exactly what is happening with the UNIX file. UNIX files don't 
support an RECFM, LRECL or BLKSIZE so specifying them on the DD results in them 
being ignored.  When the first DD specifies a dataset that supports RECFM, 
LRECL and BLKSIZE, AMATERSE now has information it needs. Secondary DD's are 
not scrutinized as much as the first dataset in a concatenation.

Maybe GIMZIP (from SMP/E) or zip from the UNIX utilities page might help.

Jon Perryman.




 From: Paul Gilmartin paulgboul...@aim.com



In other words, should I ask them whether the information in
Using Data Sets is correct?

 Can you give us some context? Why is this important or even relavent?
 
AMATERSE.  I, like many others, find it easier to FTP a
TERSEd archive to my desktop than to the z.  And I have
a directory NFS mounted to both the desktop and the z.  So:

* TOP OF DATA 
***
** AMA572I STARTING TERSE DECODE   UNPACK       20:08:51  11/07/2013 
** AMA527I  INPUT  - DDNAME : SYSUT1   DSNAME: ...PATH=.SPECIFIED...
** AMA583E  INPUT DEVICE TYPE IS UNSUPPORTED
** AMA573I TERSE COMPLETE DECODE   UNPACK       20:08:51  11/07/2013 
** AMA504I  RETURN CODE: 32
 BOTTOM OF DATA 
*

Ironically, this:

//* =
//* Temporary DS followed by UNIX file!
//*
//TESTB    EXEC  UNPACK
//SYSUT1    DD   UNIT=SYSALLDA,SPACE=(1,0),ATTRS,DSORG=PS
//          DD   PATHOPTS=ORDONLY,PATH='PATH',ATTRS
//*
//* =

... succeeds:

* TOP OF DATA 
***
** AMA572I STARTING TERSE DECODE   UNPACK       20:08:50  11/07/2013 
** AMA527I  INPUT  - DDNAME : SYSUT1   DSNAME: 
SYS13311.T200847.RA000.TERSEHFS.R0165256
** AMA528I  OUTPUT - DDNAME : SYSUT2   DSNAME: 
SYS13311.T200847.RA000.TERSEHFS.R0165255
** AMA555I  THE VALUES ARE:  BLKSIZE= 3120    LRECL=80      PACKTYPE=SPACK   
RECFM=FIXED
** AMA583I  INPUT DATASET SIZE IN BYTES: 4096 OUTPUT DATASET SIZE IN BYTES: 
15360 COMPRESSION RATIO: 26%
** AMA573I TERSE COMPLETE DECODE   UNPACK       20:08:50  11/07/2013 
** AMA504I  RETURN CODE: 0
 BOTTOM OF DATA 
*


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

Re: Aging Sysprogs = Aging Farmers

2013-11-06 Thread Michael G Phillips

 And I find cp terribly confusing - to a neophyte does it stand for 
 copy, or compare, or compress (as in disk reorganization). It might make
 more sense if I could assign an alias of COPY to it.
well...actually you can do that, quite easily:
   alias COPY=cp

I cut my teeth on DOS rel 26 many years ago as an operator. We had that 
typical (back then) rack of manuals at the console to figure out any 
problem... I quickly realized I'd never remember it all, but if I could just 
remember where to start looking, I could probably find the answer... some day.

In the Linux/Unix/AIX world it ain't much better but at least there's the 
wonderful 'man page's - great if you know what command you want to get details 
on but useless if don't. 

Now working with large mainframe software migrations to various mid-range 
systems, I have found a 'true friend' in Google... :)

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

Re: Aging Sysprogs = Aging Farmers

2013-11-06 Thread John McKown

On Wed, Nov 6, 2013 at 2:05 AM, Michael G Phillips mich...@sv-kayla.orgwrote:

  And I find cp terribly confusing - to a neophyte does it stand for
  copy, or compare, or compress (as in disk reorganization). It might make
  more sense if I could assign an alias of COPY to it.
 well...actually you can do that, quite easily:
alias COPY=cp

 I cut my teeth on DOS rel 26 many years ago as an operator. We had that
 typical (back then) rack of manuals at the console to figure out any
 problem... I quickly realized I'd never remember it all, but if I could
 just remember where to start looking, I could probably find the answer...
 some day.

 In the Linux/Unix/AIX world it ain't much better but at least there's the
 wonderful 'man page's - great if you know what command you want to get
 details on but useless if don't.


On most Linux systems, the apropos command does a keyword search for
possible matching man pages.



 Now working with large mainframe software migrations to various mid-range
 systems, I have found a 'true friend' in Google... :)

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




-- 
This is clearly another case of too many mad scientists, and not enough
hunchbacks.

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: Aging Sysprogs = Aging Farmers

2013-11-06 Thread John Gilmore

The notion that JCL is somehow hateful is widespread and not new.

In the 1970s a colleague kept telling me that [UNIVAC] Exec 8 was much
superior to JCL.   He showed me what it required to compile and
execute a FORTRAN program, which he thought compared very unfavorably
with the JCL required to do the same thing.

I investigated and found that he was right; but there was a rub: Exec
8 was not good at doing much of anything else.

Gerhard Postpischil's point is the crucial one:  JCL is a well wrought
compromise between simplicity and power.

Still, it has a bad reputation; and when the time came last year to
teach it systematically to my teenage geniuses, I opted for a
non-standard approach.  I asked each of them to write and test a
lexical breakout routine for current z/OS MVS JCL in either C or PL/I,
giving them a VDL definition of this JCL as a basis for doing so

They all succeeded.  (They are fiercely competitive, and it was all
but foregone that if one did they all would.)  Then, having mastered
the syntax and some of the semantics of JCL, they all learned to use
it very rapidly.

I am not sure that this scheme would scale up, and there are other
reasons to be wary of its generality.  Its success has, however, made
me suspicious of the low-level, brutally empirical, step-by-step,
from-simple-to-complex approaches to teaching and learning JCL that
are usual in the industry.

There is, finally, something else in play here too.

If you want to sell someone a mass-market cell phone, you make it easy
to use, even at the expense of functionality.

If, on  the other hand, a young statistician said to be that he didn't
think Tauberians were user-friendly, i would want to help him to
master whatever about them he found puzzling, but I would also make it
clear to him that they were a part of the plumbing that he needed to
master.

John Gilmore, Ashland, MA 01721 - USA

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

Re: Aging Sysprogs = Aging Farmers

2013-11-06 Thread Ian

Robin,

I know Share usually have a nice ASM training at the Conference. And you
get to attend some of the other tracks as well.

http://www.share.org/



On Tue, Nov 5, 2013 at 1:51 AM, Robin Atwood abend...@gmail.com wrote:

 Diverting the thread a tad, does anyone know where you can do an HLASM
 course? My young colleague wants to be inducted into the mysteries of the
 ancient craft and we found various IBM courses (see below) but none of them
 are currently being offered. Of course, various outfits are happy to come
 to
 your shop and give one-on-one instruction, but HR won't wear the expense of
 that.

 ES10AGB

 http://www-304.ibm.com/jct03001c/services/learning/ites.wss/gb/en?pageType=c
 ourse_descriptioncourseCode=ES10AGB
 ES34GB

 http://www-304.ibm.com/jct03001c/services/learning/ites.wss/gb/en?pageType=c
 ourse_descriptioncourseCode=ES34GB
 ES35GB

 http://www-304.ibm.com/jct03001c/services/learning/ites.wss/gb/en?pageType=c
 ourse_descriptioncourseCode=ES35GB

 He is in the UK but travel would not be a problem. Any suggestions
 gratefully received!

 Thanks
 -Robin


-- 
Ian
http://www.cicsworld.com

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

Re: Aging Sysprogs = Aging Farmers

2013-11-06 Thread David Crayford

JCL is neither simple or powerful. It's a piece of poorly designed junk that 
should never have made GA. Even it's original implementers admit that it's 
rubbish. Try explaining the reverse logic of condition codes to a youngster and 
they will die laughing. 

Hey, how do I do a loop in this code?

Forget it kid, they didn't have rewind on punch card readers. 



 On 6 Nov 2013, at 10:06 pm, John Gilmore jwgli...@gmail.com wrote:
 
 The notion that JCL is somehow hateful is widespread and not new.
 
 In the 1970s a colleague kept telling me that [UNIVAC] Exec 8 was much
 superior to JCL.   He showed me what it required to compile and
 execute a FORTRAN program, which he thought compared very unfavorably
 with the JCL required to do the same thing.
 
 I investigated and found that he was right; but there was a rub: Exec
 8 was not good at doing much of anything else.
 
 Gerhard Postpischil's point is the crucial one:  JCL is a well wrought
 compromise between simplicity and power.
 
 Still, it has a bad reputation; and when the time came last year to
 teach it systematically to my teenage geniuses, I opted for a
 non-standard approach.  I asked each of them to write and test a
 lexical breakout routine for current z/OS MVS JCL in either C or PL/I,
 giving them a VDL definition of this JCL as a basis for doing so
 
 They all succeeded.  (They are fiercely competitive, and it was all
 but foregone that if one did they all would.)  Then, having mastered
 the syntax and some of the semantics of JCL, they all learned to use
 it very rapidly.
 
 I am not sure that this scheme would scale up, and there are other
 reasons to be wary of its generality.  Its success has, however, made
 me suspicious of the low-level, brutally empirical, step-by-step,
 from-simple-to-complex approaches to teaching and learning JCL that
 are usual in the industry.
 
 There is, finally, something else in play here too.
 
 If you want to sell someone a mass-market cell phone, you make it easy
 to use, even at the expense of functionality.
 
 If, on  the other hand, a young statistician said to be that he didn't
 think Tauberians were user-friendly, i would want to help him to
 master whatever about them he found puzzling, but I would also make it
 clear to him that they were a part of the plumbing that he needed to
 master.
 
 John Gilmore, Ashland, MA 01721 - USA
 
 --
 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: Aging Sysprogs = Aging Farmers

2013-11-06 Thread Alan Field

Possibly because many of us don't run Session manager.

Here's what I get: SESSION MANAGER NOT ACTIVE - SMCOPY IGNORED in response 
to the SMCOPY command. 

Alan Field
Technical Engineer Principal
BCBS Minnesota

Phone: 651.662.3546  Mobile:  651.428.8826





From:   Steve Comstock st...@trainersfriend.com
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   11/05/2013 21:39
Subject:Re: Aging Sysprogs = Aging Farmers
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



On 11/5/2013 5:26 PM, David Crayford wrote:
 On 6/11/2013 12:37 AM, John Gilmore wrote:
 I do of course agree that z/OS is perceived to be boring, but that is
 another question.

 I don't think it's perceived as boring, certainly it's perceived as user
 hostile. Take Pauls cp command example, it's easy to copy files
 using a simple command. For those that prefer GUIs they can drag and 
drop or
 copy/paste. On the mainframe one has no choice but
 to run JCL. JCL certainly is an antique, and a very unpleasant one.


Actually, in a TSO session (analogous to a UNIX session),
you can use the SMCOPY command without JCL. It's just
that most people aren't aware of it.

ad

Covered in our courses

   TSO CLIST Programming in z/OS - 3 days
 
http://www.trainersfriend.com/TSO_Clist_REXX_Dialog_Mgr/a650descrpt.htm

   TSO REXX Programming in z/OS - 5 days
 
http://www.trainersfriend.com/TSO_Clist_REXX_Dialog_Mgr/a750descrpt.htm

/ad

--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* We are going out of business effective 30 December, 2013

* To purchase a set of our training materials at terrific prices,
   check out our Going Out Of Business Sale:

 http://www.trainersfriend.com/SpecialSale

--
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: Aging Sysprogs = Aging Farmers

On Tue, 5 Nov 2013 21:33:20 -0500, Gerhard Postpischil wrote:

IIRC, IBM has had a simple COPY command ever since TSO/E - no JCL
needed. JCL is unpleasant only if you're not used to it; I've run on
Univac, Unisys, CDC, and other systems, and found JCL to be a good
compromise of simplicity and power.
 
I believe the last time I looked for COPY in the TSO/E Commands
manual I couldn't find it.  But it was long ago; I might have forgotten
or things might have changed.

And I find cp terribly confusing - to a neophyte does it stand for
copy, or compare, or compress (as in disk reorganization). It might make
more sense if I could assign an alias of COPY to it.

Whereas it's intuitively obvious that IEBGENER means copy.  Give me a
break!  You can assign whatever alias you choose (even IEBGENER) to
cp with a single command; either as a shell alias or as a symbolic link.

-- gil

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

Re: Aging Sysprogs = Aging Farmers

2013-11-06 Thread Steve Comstock


On 11/6/2013 7:47 AM, Alan Field wrote:

Possibly because many of us don't run Session manager.

Here's what I get: SESSION MANAGER NOT ACTIVE - SMCOPY IGNORED in response
to the SMCOPY command.

Alan Field
Technical Engineer Principal
BCBS Minnesota

Phone: 651.662.3546  Mobile:  651.428.8826


Interesting. I knew that the 'SM' in 'SMCOPY' stood for
session manager, but my recent experience has been that
the SMCOPY command has always worked. Must have lucked
out in that session manager was always running where I
happened to test it.

Can you show us the actual command you issued?

Kind regards,

-Steve







From:   Steve Comstock st...@trainersfriend.com
To: IBM-MAIN@LISTSERV.UA.EDU,
Date:   11/05/2013 21:39
Subject:Re: Aging Sysprogs = Aging Farmers
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



On 11/5/2013 5:26 PM, David Crayford wrote:

On 6/11/2013 12:37 AM, John Gilmore wrote:

I do of course agree that z/OS is perceived to be boring, but that is
another question.


I don't think it's perceived as boring, certainly it's perceived as user
hostile. Take Pauls cp command example, it's easy to copy files
using a simple command. For those that prefer GUIs they can drag and

drop or

copy/paste. On the mainframe one has no choice but
to run JCL. JCL certainly is an antique, and a very unpleasant one.



Actually, in a TSO session (analogous to a UNIX session),
you can use the SMCOPY command without JCL. It's just
that most people aren't aware of it.

ad

Covered in our courses

TSO CLIST Programming in z/OS - 3 days

http://www.trainersfriend.com/TSO_Clist_REXX_Dialog_Mgr/a650descrpt.htm

TSO REXX Programming in z/OS - 5 days

http://www.trainersfriend.com/TSO_Clist_REXX_Dialog_Mgr/a750descrpt.htm

/ad

--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* We are going out of business effective 30 December, 2013

* To purchase a set of our training materials at terrific prices,
check out our Going Out Of Business Sale:

  http://www.trainersfriend.com/SpecialSale

--
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: Aging Sysprogs = Aging Farmers

2013-11-06 Thread Alan Field

Simply from option 6 I entered SMCOPY

Alan Field
Technical Engineer Principal
BCBS Minnesota

Phone: 651.662.3546  Mobile:  651.428.8826





From:   Steve Comstock st...@trainersfriend.com
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   11/06/2013 08:58
Subject:Re: Aging Sysprogs = Aging Farmers
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



On 11/6/2013 7:47 AM, Alan Field wrote:
 Possibly because many of us don't run Session manager.

 Here's what I get: SESSION MANAGER NOT ACTIVE - SMCOPY IGNORED in 
response
 to the SMCOPY command.

 Alan Field
 Technical Engineer Principal
 BCBS Minnesota

 Phone: 651.662.3546  Mobile:  651.428.8826

Interesting. I knew that the 'SM' in 'SMCOPY' stood for
session manager, but my recent experience has been that
the SMCOPY command has always worked. Must have lucked
out in that session manager was always running where I
happened to test it.

Can you show us the actual command you issued?

Kind regards,

-Steve






 From:   Steve Comstock st...@trainersfriend.com
 To: IBM-MAIN@LISTSERV.UA.EDU,
 Date:   11/05/2013 21:39
 Subject:Re: Aging Sysprogs = Aging Farmers
 Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



 On 11/5/2013 5:26 PM, David Crayford wrote:
 On 6/11/2013 12:37 AM, John Gilmore wrote:
 I do of course agree that z/OS is perceived to be boring, but that is
 another question.

 I don't think it's perceived as boring, certainly it's perceived as 
user
 hostile. Take Pauls cp command example, it's easy to copy files
 using a simple command. For those that prefer GUIs they can drag and
 drop or
 copy/paste. On the mainframe one has no choice but
 to run JCL. JCL certainly is an antique, and a very unpleasant one.


 Actually, in a TSO session (analogous to a UNIX session),
 you can use the SMCOPY command without JCL. It's just
 that most people aren't aware of it.

 ad

 Covered in our courses

 TSO CLIST Programming in z/OS - 3 days

 http://www.trainersfriend.com/TSO_Clist_REXX_Dialog_Mgr/a650descrpt.htm

 TSO REXX Programming in z/OS - 5 days

 http://www.trainersfriend.com/TSO_Clist_REXX_Dialog_Mgr/a750descrpt.htm

 /ad

 --

 Kind regards,

 -Steve Comstock
 The Trainer's Friend, Inc.

 303-355-2752
 http://www.trainersfriend.com

 * We are going out of business effective 30 December, 2013

 * To purchase a set of our training materials at terrific prices,
 check out our Going Out Of Business Sale:

   http://www.trainersfriend.com/SpecialSale

 --
 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: Aging Sysprogs = Aging Farmers

On Wed, 6 Nov 2013 02:05:33 -0600, Michael G Phillips wrote:

In the Linux/Unix/AIX world it ain't much better but at least there's the 
wonderful 'man page's - great if you know what command you want to get details 
on but useless if don't. 

apropos helps some.

Now working with large mainframe software migrations to various mid-range 
systems, I have found a 'true friend' in Google... :)

Apparently such a true friend that IBM is abandoning publibz and
telling customers to use Google instead.

-- gil

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

Re: Aging Sysprogs = Aging Farmers

2013-11-06 Thread Steve Comstock


On 11/6/2013 8:04 AM, Alan Field wrote:

Simply from option 6 I entered SMCOPY

Alan Field
Technical Engineer Principal
BCBS Minnesota

Phone: 651.662.3546  Mobile:  651.428.8826


Ah. In the TSO Command Reference you will see:

If the source and target of the copy request are both data sets, (SYSOUT or
QSAM), you do not have to be logged on under the Session Manager to use the
SMCOPY command.


Try something like

smcopy fds(from_datasetname) tds(to_datasetname)

note that if 'to_datasetname' does not exist, SMCOPY will create it.


you can also add the option notrans to ensure no translation
of non-printable characters to blanks (e.g., if you have
packed decimal or binary data fields)

you can also add the option 'line(start:end)' to copy a subset of
the source file.

Kind regards,

-Steve








From:   Steve Comstock st...@trainersfriend.com
To: IBM-MAIN@LISTSERV.UA.EDU,
Date:   11/06/2013 08:58
Subject:Re: Aging Sysprogs = Aging Farmers
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



On 11/6/2013 7:47 AM, Alan Field wrote:

Possibly because many of us don't run Session manager.

Here's what I get: SESSION MANAGER NOT ACTIVE - SMCOPY IGNORED in

response

to the SMCOPY command.

Alan Field
Technical Engineer Principal
BCBS Minnesota

Phone: 651.662.3546  Mobile:  651.428.8826


Interesting. I knew that the 'SM' in 'SMCOPY' stood for
session manager, but my recent experience has been that
the SMCOPY command has always worked. Must have lucked
out in that session manager was always running where I
happened to test it.

Can you show us the actual command you issued?

Kind regards,

-Steve







From:   Steve Comstock st...@trainersfriend.com
To: IBM-MAIN@LISTSERV.UA.EDU,
Date:   11/05/2013 21:39
Subject:Re: Aging Sysprogs = Aging Farmers
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



On 11/5/2013 5:26 PM, David Crayford wrote:

On 6/11/2013 12:37 AM, John Gilmore wrote:

I do of course agree that z/OS is perceived to be boring, but that is
another question.


I don't think it's perceived as boring, certainly it's perceived as

user

hostile. Take Pauls cp command example, it's easy to copy files
using a simple command. For those that prefer GUIs they can drag and

drop or

copy/paste. On the mainframe one has no choice but
to run JCL. JCL certainly is an antique, and a very unpleasant one.



Actually, in a TSO session (analogous to a UNIX session),
you can use the SMCOPY command without JCL. It's just
that most people aren't aware of it.

ad

Covered in our courses

 TSO CLIST Programming in z/OS - 3 days

http://www.trainersfriend.com/TSO_Clist_REXX_Dialog_Mgr/a650descrpt.htm

 TSO REXX Programming in z/OS - 5 days

http://www.trainersfriend.com/TSO_Clist_REXX_Dialog_Mgr/a750descrpt.htm

/ad

--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* We are going out of business effective 30 December, 2013

* To purchase a set of our training materials at terrific prices,
 check out our Going Out Of Business Sale:

   http://www.trainersfriend.com/SpecialSale

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



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

Re: Aging Sysprogs = Aging Farmers

On Wed, 6 Nov 2013 22:45:01 +0800, David Crayford wrote:

JCL is neither simple or powerful. It's a piece of poorly designed junk that 
should never have made GA. Even it's original implementers admit that it's 
rubbish. Try explaining the reverse logic of condition codes to a youngster 
and they will die laughing. 

Hey, how do I do a loop in this code?

Forget it kid, they didn't have rewind on punch card readers. 
 
With all due respect (even I can muster all the respect due to JCL),
the declarative character, as opposed to procedural, of JCL provides
a couple advantages:

o It's possible to determine at initiation (some of) the resources
  needed by a job and assure that they will be available, thereby
  avoiding (some) deadlocks.  (When we had our first couple
  systems and no GRS, linkage editor reserve deadlocks were a
  recurrent problem.)

o Auditors can tell by inspection who's doing what to whom.  Thei
  like that.

It would be impossible to do either in a Turing-complete command
language.

The reverse logic of condition codes probably was intuitive to an
assembler or FORTRAN programmer who thought of branching
around a statement.

DOS, like TSO, places the data set allocations before the command
(phase?), which seems more natural than the JCL convention.
After all, which do you do first?  Oops.  I forgot: JCL is declarative
rather than procedural.

JCL met the needs of the 360 well.  This is a different century.

-- gil

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

Re: Aging Sysprogs = Aging Farmers

2013-11-06 Thread David Crayford

 On 6 Nov 2013, at 11:32 pm, Paul Gilmartin paulgboul...@aim.com wrote:
 
 On Wed, 6 Nov 2013 22:45:01 +0800, David Crayford wrote:
 
 JCL is neither simple or powerful. It's a piece of poorly designed junk that 
 should never have made GA. Even it's original implementers admit that it's 
 rubbish. Try explaining the reverse logic of condition codes to a youngster 
 and they will die laughing. 
 
 Hey, how do I do a loop in this code?
 
 Forget it kid, they didn't have rewind on punch card readers.
 With all due respect (even I can muster all the respect due to JCL),
 the declarative character, as opposed to procedural, of JCL provides
 a couple advantages:
 
 o It's possible to determine at initiation (some of) the resources
  needed by a job and assure that they will be available, thereby
  avoiding (some) deadlocks.  (When we had our first couple
  systems and no GRS, linkage editor reserve deadlocks were a
  recurrent problem.)
 
 o Auditors can tell by inspection who's doing what to whom.  Thei
  like that.
 
 It would be impossible to do either in a Turing-complete command
 language.
 

I'm not so sure about that. CL has declare commands which does the same thing. 
And it's Turing complete. 

 The reverse logic of condition codes probably was intuitive to an
 assembler or FORTRAN programmer who thought of branching
 around a statement.
 
 DOS, like TSO, places the data set allocations before the command
 (phase?), which seems more natural than the JCL convention.
 After all, which do you do first?  Oops.  I forgot: JCL is declarative
 rather than procedural.
 
 JCL met the needs of the 360 well.  This is a different century.
 
 -- 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: Aging Sysprogs = Aging Farmers

On Wed, 6 Nov 2013 08:14:04 -0700, Steve Comstock wrote:

Ah. In the TSO Command Reference you will see:

If the source and target of the copy request are both data sets, (SYSOUT or
QSAM), you do not have to be logged on under the Session Manager to use the
SMCOPY command.
 
What's a data set?  What's not a data set?  I believe the obvious
authority should be Using Data Sets, which avers in an early
section, that a data set can be many things (from memory): DASD,
tape, terminal, card reader, punch, printer, UNIX file, ...

(And, no, I've failed using that citation to IBM support when they
tell me, No, that needs to be a data set.)

-- gil

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

Re: Aging Sysprogs = Aging Farmers

2013-11-06 Thread Steve Comstock


On 11/6/2013 8:45 AM, Paul Gilmartin wrote:

On Wed, 6 Nov 2013 08:14:04 -0700, Steve Comstock wrote:


Ah. In the TSO Command Reference you will see:

If the source and target of the copy request are both data sets, (SYSOUT or
QSAM), you do not have to be logged on under the Session Manager to use the
SMCOPY command.


What's a data set?  What's not a data set?  I believe the obvious
authority should be Using Data Sets, which avers in an early
section, that a data set can be many things (from memory): DASD,
tape, terminal, card reader, punch, printer, UNIX file, ...

(And, no, I've failed using that citation to IBM support when they
tell me, No, that needs to be a data set.)

-- gil

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



Good question, Paul. I no longer have a system to test on.
How about trying SMCOPY with z/OS UNIX files as input and / or
output and letting us know how it works?

Kind regards,

-Steve

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

Re: Aging Sysprogs = Aging Farmers

2013-11-06 Thread Kirk Talman

IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 
11/06/2013 10:32:09 AM:

 From: Paul Gilmartin paulgboul...@aim.com

 The reverse logic of condition codes probably was intuitive to an
 assembler or FORTRAN programmer who thought of branching
 around a statement.

I remember first seeing CCs in 1966 while in graduate school in physics 
and thinking that somewhere there was a mathematician who understood this, 
but humans would never.  My opinion has not changed in 47 years.  A 
virtual beer to whoever thought up the JCL IF statement.

-
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you 

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

Re: Aging Sysprogs = Aging Farmers

2013-11-06 Thread Pommier, Rex

Steve,

That piqued my interest so I tried it (obviously a non-exhaustive test).  
Here's what I got:

.Menu  List  Mode  Functions  Utilities  Help   
  
.  
‹‹‹
.ISPF Command Shell 
  
.  Enter TSO or Workstation commands below: 
  
.   
  
.  === smcopy fds(/etc/logs) tds(/u/rex/log-deleteme)  
  
.   
  
.   
  


 IKJ56700A ENTER INPUT SOURCE DATASET NAME -
  
/etc/logs  
 IKJ56709I INVALID DATA SET NAME, /etc/logs
 IKJ56718A REENTER THIS OPERAND+ - 
 FDS: 


Doing a HELP on SMCOPY part of what I got back was this:

NOTE - DATA SETS MUST BE SEQUENTIAL OR MEMBER OF A PARTITIONED 
DATA SET AND EITHER FIXED OR VARIABLE LENGTH RECORDS.   
  - WHEN INPUT AND OUTPUT ARE BOTH DATA SETS (SYSOUT OR QSAM)   
THIS COMMAND CAN BE EXECUTED IN THE BACKGROUND. 

So it appears to me that SMCOPY hasn't been updated to support unix files.
 
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Comstock
Sent: Wednesday, November 06, 2013 9:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Aging Sysprogs = Aging Farmers

On 11/6/2013 8:45 AM, Paul Gilmartin wrote:
 On Wed, 6 Nov 2013 08:14:04 -0700, Steve Comstock wrote:

 Ah. In the TSO Command Reference you will see:

 If the source and target of the copy request are both data sets, (SYSOUT or
 QSAM), you do not have to be logged on under the Session Manager to use the
 SMCOPY command.

 What's a data set?  What's not a data set?  I believe the obvious
 authority should be Using Data Sets, which avers in an early
 section, that a data set can be many things (from memory): DASD,
 tape, terminal, card reader, punch, printer, UNIX file, ...

 (And, no, I've failed using that citation to IBM support when they
 tell me, No, that needs to be a data set.)

 -- gil

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


Good question, Paul. I no longer have a system to test on.
How about trying SMCOPY with z/OS UNIX files as input and / or
output and letting us know how it works?

Kind regards,

-Steve

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

JCL (was: Re: Aging Sysprogs = Aging Farmers)

2013-11-06 Thread Pew, Curtis G

On Nov 6, 2013, at 8:45 AM, David Crayford dcrayf...@gmail.com wrote:

 Hey, how do I do a loop in this code?
 
 Forget it kid, they didn't have rewind on punch card readers. 

I think much of the disdain for JCL comes from inaccurate expectations set by 
calling it a “language”. JCL is *not a programming language*. It’s not even a 
minimal scripting language. It’s the punch-card-technology equivalent of 
gestures like double-clicking an app icon or selecting “open” from a file menu 
in a modern GUI.

Yes, it’s far from perfect. The condition code thing is pretty goofy (although 
you’ve been able to use IF constructs instead for over two decades) and a lot 
of keywords and values are pretty obscure. But for what it was actually 
designed to do, it works pretty well. 

-- 
Curtis Pew (c@its.utexas.edu)
ITS Systems Core
The University of Texas at Austin

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

Re: Aging Sysprogs = Aging Farmers