Re: JCL CROSS-REFERENCE Utilities (OT for Paul, Rick, and Shmuel)

[Shmuel Metz (Seymour J.)]

In , on 10/08/2011
   at 12:29 AM, Anne & Lynn Wheeler  said:

>xt/370 & at/370 was motorola 68k

As I recall, it was two of them, one with standard 68000 ROM and one
with a tailored ROM.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL CROSS-REFERENCE Utilities (OT for Paul, Rick, and Shmuel)

[Anne & Lynn Wheeler]

glen herrmannsfeldt  writes:
> I once had PL/I (F) running on an AT/370, about 5 minutes 
> to compiler a five line program.  

re:
http://www.garlic.com/~lynn/2011m.html#61 JCL CROSS-REFERENCE Utilities (OT for 
Paul, Rick, and Shmuel)
http://www.garlic.com/~lynn/2011m.html#62 JCL CROSS-REFERENCE Utilities (OT for 
Paul, Rick, and Shmuel)
http://www.garlic.com/~lynn/2011m.html#63 JCL CROSS-REFERENCE Utilities (OT for 
Paul, Rick, and Shmuel)

xt/370 & at/370 was motorola 68k fiddled to execute 370 instructions at
about 100kips. the original cardset had 384k bytes of 370 memory ...
which ran special modified vm370 kernel plus the real storage for demand
paging of cms. the 370 card had no i/o ... vm370 was modified to send
messages to cp88 running on the intel chip ... and all i/o was done by
cp88 running on the pc side ... and then transfers between vm370 and
cp88.

it started out code-named "washington" and the pc/xt had 100ms per
transfer disk ... each page transfer or cms file record transfer took
100ms on pc/xt hard disk (maximum aggregate rate would be less than 10
transfer per second with vm370/cp88 overhead & transferlatency). After
fix vm370 kernel ... there was very little left of the 384k bytes for
paging cms and application virtual memory ... resulting in page
thrashing. I benchmarked and showed significant page thrashing even for
realy trivial operations.

I got blamed for six month schedule slip in washington while they
re-engineered the cards to add another 128kbytes of 370 memory (increase
from 384kbytes to 512kbytes) to minimize virtual memory page thrashing
(i done a bunch of benchmarks showing page thrashing)

pli compiler would have both significant virtual memory thrashing (even
with the additional 128kbyte real storage ... i don't remember exactly
now ... but vm370 fixed kernel storage was possibly something like
150kbytes ... with 512kbyte real storage ... that would leave
approx. 350kbytes of real storage for cms virtual memory ... the cms
kernel, cms system services ... and the pli compiler and data areas.

the upgrade from xt/370 to at/370 met that cp88 ran on somewhat faster
processor and the hard disks were faster ... 5 minutes is 300 seconds
... say if you are lucky maybe 15 disk record transfers per second
... 4500 disk record transfers ... which is page thrashing, loading pli
compiler execution, and all other file i/o.

A big issue was that cms was relatively bloated in terms of its use of
file i/o ... and all of the cms compilers were brought over from mvs
using simulation of systerm services ... which were really bloated in
terms of use of file i/o. remapping that environment to a PC ... using
PC disks instead of mainframe disks was quite tramatic ... compared to
similar applications developed specifically for pc environment.

Even running applications that fit in the available 370 real storage
(and didn't page thrash) ... the 100kip 370 processor wasn't usually the
bottleneck ... it was the enormous difference between thruput of
mainframe disks and pc disks. Of course that wouldn't be a problem these
days because both PCs and mainframes use the same disk technology
... PCs using native disk technolgy and many mainframes using emulated
CKD on top of native disks (there hasn't been real ckd disks for
decades).

I did some prototype work for washington with my cms paged mapped
filesystem for washington ... on mainframe with 3380 i could possible
three times improved (300%) throughput compared to standard cms
filesystem for applications that did moderate amounts of file
i/o. ... but still couldn't achieve look&feel of cms with real mainframe
disks. misc. past posts mentioning memory mapped filesystem for cms
... orginally done for cp67 and then ported to vm370
http://www.garlic.com/~lynn/submain.html#mmap

follow-on to at/370 was a74 ... separate box with 4mbytes of 370 real
storage and 350kip processor. old long-winded post that includes copy of
A74 product description at the bottom
http://www.garlic.com/~lynn/2002d.html#4

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL CROSS-REFERENCE Utilities (OT for Paul, Rick, and Shmuel)

[Anne & Lynn Wheeler]

l...@garlic.com (Anne & Lynn Wheeler) writes:
> APL is an interpreted language ... after doing lots of work to optimize
> virtual paging and aggregate real storage footprint ...  APL remained
> computational intensive. That contributed to HONE having growing number
> of high-end multiprocessors in loosely-coupled, single-system-image
> configuration ... which had front-end process that did load-balancing
> logon (slightly analogous to web search engines spreading load across
> available syustems).

re:
http://www.garlic.com/~lynn/2011m.html#61 JCL CROSS-REFERENCE Utilities (OT for 
Paul, Rick, and Shmuel)
http://www.garlic.com/~lynn/2011m.html#62 JCL CROSS-REFERENCE Utilities (OT for 
Paul, Rick, and Shmuel)

at the science center, there was a lot of performance algorithm, tuning,
monitoring, simulation and modeling work ... some of it eventually
evolving into things like capacity planning.

one of the efforts was an system performance analytical model
implemented in APL. A version of this was modified for HONE that was fed
system activity from all the loosely-coupled systems and used to decide
which machine each login should be directed to.

a different variation was made available on HONE as the "performance
predictor"  branch people could gather customer workload and system
characteristics and input into the "performance predictor" and ask
"what-if" questions ... like what would happen in the case of customer
workload and/or system configuration changes.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL CROSS-REFERENCE Utilities (OT for Paul, Rick, and Shmuel)

[Anne & Lynn Wheeler]

ps2...@yahoo.com (Ed Gould) writes:
> My memory sort of agrees with the above and I will accept your memory.
>
> We used to have a full time SE from sometime in 196x's to the mid-late 1970's.
>
> My recollection from talking with him was that HONE was used for all
> configuration(s).  Was that not the case? I still remember (albeit
> vaguely ) looking at some output (paper) from a hone session and being
> asked about memory and the like.


re:
http://www.garlic.com/~lynn/2011m.html#61 JCL CROSS-REFERENCE Utilities (OT for 
Paul, Rick, and Shmuel)

original apl\360 would allocate next unused storage on every assignment
 when it exhausted all of (workspace) storage ... it would "garbage
collect" and coalesce all allocated variables to bottom of the
workspace. this resulted in apl\360 repeatedly using every storage
location in the workspace ... even for small problems ... as long as
there were assignments (didn't re-use previous allocated storage for
variable). for small workspaces (16k or 32k bytes) ... that were
completely swapped ... it didn't really matter.

moving to cms\apl with demand-paged "virtual" workspace that was
hundreds of kbytes or multiple megabytes ... constantly touching every
possible workspace location led to page thrashing. one of the first
things that needed to be redone for cms\apl was redo how apl managed its
workspace storage.

HONE APL executable image was shared across all cms virtual machines
... reducing aggregate real storage footprint. Later work was done to
include significant pieces of APL workspace/programs in shared segments
... further reducing real storage footprint.

APL is an interpreted language ... after doing lots of work to optimize
virtual paging and aggregate real storage footprint ...  APL remained
computational intensive. That contributed to HONE having growing number
of high-end multiprocessors in loosely-coupled, single-system-image
configuration ... which had front-end process that did load-balancing
logon (slightly analogous to web search engines spreading load across
available syustems).

Many sales&marketing people spent their entire time in a session manager
implemented in APL (and automatically invoked at login) called "SEQUIOA"
...  and never or rarely directly exposed to vm370/cms. Eventually for
some of the heavily used, most compute intensive "configurators"
... they were recoded in FORTRAN and a process created that allowed APL
to invoked FORTRAN programs as sub-program ... which could achieve a
factor of 100 times reduction in processor use.

There was some growing/emerging native CMS use for writting (customer)
proposals, RFP responses and other document preperation ... as well as
growing use of email (like PROFS). recent (linkedin) discussion about
PROFS (and the internal network)
http://www.garlic.com/~lynn/2011m.html#60 

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL CROSS-REFERENCE Utilities (OT for Paul, Rick, and Shmuel)

[Ed Gould]

---SNIP---

HONE also started offering marketing&sales applications implemented in
cms\apl. Eventually the sales&marketing use began to dominate all HONE
use and the virtual guest use died off. By the mid-70s *ALL* mainframe
orders had to be first processed by HONE aids&configurators ... all
implemented in APL (and HONE virtual machine clones were started to
sprout up all over the world).

HONE was part of the sales&marketing organization and periodically some
branch manager would be promoted into executive position that included
responsibility for HONE ... and they would find to the horror that the
company (especially sales&marketing) ran on vm370 (not *MVS*). They
would come to believe that their career in the corporation would be made
if they could convert HONE to MVS. A huge amount of resources would go
into a MVS migration attempt and eventually fail ... then there would
eventually be executive shuffle and the whole thing forgotten until the
next new executive.

--SNIP

Anne:

My memory sort of agrees with the above and I will accept your memory.

We used to have a full time SE from sometime in 196x's to the mid-late 1970's.

My recollection from talking with him was that HONE was used for all 
configuration(s).
Was that not the case? I still remember (albeit vaguely ) looking at some 
output (paper) from a hone session and being asked
about memory and the like.

Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL CROSS-REFERENCE Utilities (OT for Paul, Rick, and Shmuel)

[Anne & Lynn Wheeler]

jrobe...@dhs.state.ia.us (Roberts, John J) writes:
> I'm surprised the old-timers didn't comment on my mention of APL.
> This was the original "write-only" language - maintenance was only
> possible by the original author.  It was very heavily touted by IBM in
> the early 70's.

somewhat because of litigation, 23jun69 unbundling announcement started
charging for application software (but case was made that kernel
software would still be free), se services, maintenance, etc.

up until then a lot of se training was journeyman/apprentice as part
of large groups of SEs at customer site. after 23jun69, nobody could
figure out how to have all that SE training using customer resources
w/o charging the customer for it. to address the issue several cp67
virtual machine datacenters were created to provide branch office
SEs ability to login remotely and practice guest operating system
in virtual machine. This was the HONE system ... some past posts:
http://www.garlic.com/~lynn/subtopic.html#hone
and some old email
http://www.garlic.com/~lynn/lhwemail.html#hone

the science center ... some past posts
http://www.garlic.com/~lynn/subtopic.html#545tech

besides virtual machines, internal network, a bunch of other stuff, also
ported apl\360 to cms for cms\apl. cms\apl workspaces were now as large
as virtual address space size (which required rewritting how apl managed
it workspace allocation) as compared to common 16k or 32kbytes in
apl\360 ... also an API was added to cms\apl that allowed invoking cms
system services like file i/o.

The combination allowed cms\apl to be used for real-world applications
... for instance the business planners in armonk loaded the most
valuable of corporate information (detailed customer data) on the
cambridge system and implemented business models in cms\apl. This
required some security issues since the cambridge cp67/cms system was
also used by some number of non-employees from various educational
institutions in the boston/cambridge area.

HONE also started offering marketing&sales applications implemented in
cms\apl. Eventually the sales&marketing use began to dominate all HONE
use and the virtual guest use died off. By the mid-70s *ALL* mainframe
orders had to be first processed by HONE aids&configurators ... all
implemented in APL (and HONE virtual machine clones were started to
sprout up all over the world).

HONE was part of the sales&marketing organization and periodically some
branch manager would be promoted into executive position that included
responsibility for HONE ... and they would find to the horror that the
company (especially sales&marketing) ran on vm370 (not *MVS*). They
would come to believe that their career in the corporation would be made
if they could convert HONE to MVS. A huge amount of resources would go
into a MVS migration attempt and eventually fail ... then there would
eventually be executive shuffle and the whole thing forgotten until the
next new executive.

Recent (linkedin) discussion about several features implemented for the
HONE vm370 operation in the late 70s, that are finally in the process of
being included in zVM ... aka from the annals of release no software
before its time:
http://www.garlic.com/~lynn/2011m.html#46 From The Annals of Release No 
Software Before Its Time
http://www.garlic.com/~lynn/2011m.html#47 From The Annals of Release No 
Software Before Its Time
http://www.garlic.com/~lynn/2011m.html#59 From The Annals of Release No 
Software Before Its Time

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL CROSS-REFERENCE Utilities (OT for Paul, Rick, and Shmuel)

[Ed Gould]

Shmuel,

We had 512K and ran MFT two or II. At the end just before I left we had a TP 
system that ran in p0 on 2260's.

The rdr & wtr ran in p1 and p2-p6 ran jobs p1also ran IBM utilities . If I ever 
said MVT  I was in error.

Ed



On Oct 7, 2011, at 3:30 PM, "Shmuel Metz (Seymour J.)" 
 wrote:

> In <1318007771.19748.yahoomailmob...@web161403.mail.bf1.yahoo.com>, on
> 10/07/2011
>   at 10:16 AM, Ed Gould  said:
> 
>> This goes back a lot of years but our systems each  had 512k and we
>> ran 6 jobs. Granted the small regions were 64k but it did work.
> 
> Are you sure it wasn't MFT II? 6 64KiB regions would only leave 128
> KiB for OS/360. 
> 
> -- 
> Shmuel (Seymour J.) Metz, SysProg and JOAT
> ISO position; see  
> 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...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL CROSS-REFERENCE Utilities (OT for Paul, Rick, and Shmuel)

[Shmuel Metz (Seymour J.)]

In <1318007771.19748.yahoomailmob...@web161403.mail.bf1.yahoo.com>, on
10/07/2011
   at 10:16 AM, Ed Gould  said:

> This goes back a lot of years but our systems each  had 512k and we
>ran 6 jobs. Granted the small regions were 64k but it did work.

Are you sure it wasn't MFT II? 6 64KiB regions would only leave 128
KiB for OS/360. 
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL CROSS-REFERENCE Utilities (OT for Paul, Rick, and Shmuel)

[Shmuel Metz (Seymour J.)]

In
<93891f43642f3c419a7d75acc2b1db6f3bfbbcd...@exchangemb2.dhs.state.ia.us>,
on 10/07/2011
   at 01:11 PM, "Roberts, John J"  said:

>This was all very tongue in cheek, but much of what I said is based
>upon my reality back in 1970.  I did indeed work on a 512KB S360/65
>system running release 19.  And seven concurrent jobs might have
>actually been possible since the standard region was 56K and we
>wrote a lot of code using overlays.

Leaving 120 KiB for the system? Again, MFT II is more plausible than
MVT.

>I'm surprised the old-timers didn't comment on my mention of APL. 

Why?

>This was the original "write-only" language

It was possible to write readanle APL. The write-only code was part of
the hacker culture, not intrinsic to the language.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL CROSS-REFERENCE Utilities (OT for Paul, Rick, and Shmuel)

[Roberts, John J]

(2) Upgraded our OS from OS/MFT to OS/MVT.  We can now run seven jobs 
concurrently!!!

>>>H, I'm smelling something fishy. What resources are used concurrently?

In 512 KiB? Not bllody likely!

>>>Those programmers and their jobs are probably very economically with all 
>>>those bits and bytes... :-D

This was all very tongue in cheek, but much of what I said is based upon my 
reality back in 1970.  I did indeed work on a 512KB S360/65 system running 
release 19.  And seven concurrent jobs might have actually been possible since 
the standard region was 56K and we wrote a lot of code using overlays.

I'm surprised the old-timers didn't comment on my mention of APL.  This was the 
original "write-only" language - maintenance was only possible by the original 
author.  It was very heavily touted by IBM in the early 70's.

John

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL CROSS-REFERENCE Utilities (OT for Paul, Rick, and Shmuel)

[Elardus Engelbrecht]

Shmuel Metz (Seymour J.)  wrote:

>>(2) Upgraded our OS from OS/MFT to OS/MVT.  We can now run seven jobs 
>>concurrently!!!

H, I'm smelling something fishy. What resources are used concurrently?

>In 512 KiB? Not bllody likely!

Those programmers and their jobs are probably very economically with all those 
bits and bytes... :-D

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL CROSS-REFERENCE Utilities (OT for Paul, Rick, and Shmuel)

[Ed Gould]

 This goes back a lot of years but our systems each  had 512k and we ran 6 
jobs. Granted the small regions were 64k but it did work.

Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL CROSS-REFERENCE Utilities (OT for Paul, Rick, and Shmuel)

[Shmuel Metz (Seymour J.)]

In
<93891f43642f3c419a7d75acc2b1db6f3bfbbcd...@exchangemb2.dhs.state.ia.us>,
on 10/06/2011
   at 03:58 PM, "Roberts, John J"  said:

>(2) Upgraded our OS from OS/MFT to OS/MVT.  We can now run seven jobs
>concurrently!!!

In 512 KiB? Not bllody likely!

>(5) We now have a 2780 RJE terminal. 

Have you ditched the STR terminals?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL CROSS-REFERENCE Utilities (OT for Paul, Rick, and Shmuel)

[Rick Fochtman]

--


HA HA HA

You guys are just jealous.  We have been making great strides here are Trailing 
Edge Computers.  Things we have achieved lately:
(1) Upgraded from S360/30 to a S360/65 with 512 KILOBYTES of core memory.
(2) Upgraded our OS from OS/MFT to OS/MVT.  We can now run seven jobs 
concurrently!!!
(3) Changed all our 2311 DASD to 2314 DASD. Now we can put almost 30 million bytes of data per pack, which should be enough for 50 years! 
(4) We are now entering the SPACE AGE with the new 2260 display system!  Just think - transaction processing in real time with responses in under 5 seconds!
(5) We now have a 2780 RJE terminal.  Now the users in the annex can run their jobs without needing to cross the street!  
(6) Our expanded capacity has allowed us to start using high level languages for some programs.  On the advice of our excellent IBM SE we are going to use PL/I and RPG!

(7) Some of our engineers are enthusiastic about the new APL language.  It 
allows them to write complex algorithms in just a few lines of code!  But I 
have my doubts, since I can't seem to figure what some of these programs do, 
and I think I am pretty smart.
(8) There is something new called SCRIPT.  It is supposed to allow us to print out documentation in lower case!  But my CE tells me that I need to get a TN chain for my 1403 printer for this to work.  


So before you guys start looking down your noses at TEC, compare!
 


---
Didn't you guys also get the very last shipment of 2321 Data Cell drives 
as well?


NOODLE PICKERS RULE!!!  (g, d, & r)

Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL CROSS-REFERENCE Utilities (OT for Paul, Rick, and Shmuel)

[Roberts, John J]

>>>My use was deliberate, suggesting that PROCs and temp DSNs,
>>>two facilities his client considers ultramodern, antedate the 029.

HA HA HA

You guys are just jealous.  We have been making great strides here are Trailing 
Edge Computers.  Things we have achieved lately:
(1) Upgraded from S360/30 to a S360/65 with 512 KILOBYTES of core memory.
(2) Upgraded our OS from OS/MFT to OS/MVT.  We can now run seven jobs 
concurrently!!!
(3) Changed all our 2311 DASD to 2314 DASD. Now we can put almost 30 million 
bytes of data per pack, which should be enough for 50 years! 
(4) We are now entering the SPACE AGE with the new 2260 display system!  Just 
think - transaction processing in real time with responses in under 5 seconds!
(5) We now have a 2780 RJE terminal.  Now the users in the annex can run their 
jobs without needing to cross the street!  
(6) Our expanded capacity has allowed us to start using high level languages 
for some programs.  On the advice of our excellent IBM SE we are going to use 
PL/I and RPG!
(7) Some of our engineers are enthusiastic about the new APL language.  It 
allows them to write complex algorithms in just a few lines of code!  But I 
have my doubts, since I can't seem to figure what some of these programs do, 
and I think I am pretty smart.
(8) There is something new called SCRIPT.  It is supposed to allow us to print 
out documentation in lower case!  But my CE tells me that I need to get a TN 
chain for my 1403 printer for this to work.  

So before you guys start looking down your noses at TEC, compare!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL CROSS-REFERENCE Utilities

[Rick Fochtman]

Where does he find tech support to service his 026 keypunch?
 


---
And does he use an old 12-button WrightLine desktop manual punch for a 
backup??  (g,d & r)


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL CROSS-REFERENCE Utilities

[Rick Fochtman]

Where does he find tech support to service his 026 keypunch?
   



ITYM 029, and they will be upgrading to 129 RSN.
 


--
Might really be a 026, with multi-punch to convert certain DCBIC chars 
to EBCDIC. Stranger things have happened.  :-)


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL CROSS-REFERENCE Utilities

[Paul Gilmartin]

On Thu, 6 Oct 2011 10:12:10 -0500, Shmuel Metz (Seymour J.) 
 wrote:

>In <7211762809081369.wa.paulgboulderaim@bama.ua.edu>, on
>10/06/2011
>   at 12:50 AM, Paul Gilmartin  said:
>
>>Where does he find tech support to service his 026 keypunch?
>
>ITYM 029, and they will be upgrading to 129 RSN.
> 
My use was deliberate, suggesting that PROCs and temp DSNs,
two facilities his client considers ultramodern, antedate the 029.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL CROSS-REFERENCE Utilities

[Shmuel Metz (Seymour J.)]

In <7211762809081369.wa.paulgboulderaim@bama.ua.edu>, on
10/06/2011
   at 12:50 AM, Paul Gilmartin  said:

>Where does he find tech support to service his 026 keypunch?

ITYM 029, and they will be upgrading to 129 RSN.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL CROSS-REFERENCE Utilities

[Paul Gilmartin]

On Wed, 5 Oct 2011 12:24:12 -0500, Roberts, John J wrote:

>My current client has long avoided any of the "modern" JCL enhancements. For 
>example, PROCs are very rare.  As are temporary datasets.
> 
Where does he find tech support to service his 026 keypunch?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL CROSS-REFERENCE Utilities

[Schwarz, Barry A]

CA Technologies has a product called JCLCheck.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Roberts, John J
> Sent: Wednesday, October 05, 2011 10:24 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: JCL CROSS-REFERENCE Utilities
>
> My current client has long avoided any of the "modern" JCL enhancements.
> For example, PROCs are very rare.  As are temporary datasets.
>
> I am trying to upgrade some of the batch apps with
> PROC/JCLLIB/SET/INCLUDE/IF etc.
>
> One of the impediments to the upgrade is the existence of custom JCL XREF
> tools.  For example, whereas before they may have coded DSN=X470.C100(+1),
> in the new scheme they are likely to see DSN=&C100XDSN(+1) where &C100XDSN
> is a SET variable within an INCLUDE member.  So I am betting that the
> homebrew XREF tools won't work.

snip

> So my questions for listers: which of these tools is a good value
> (compromise between cost and functionality)?  And which is the most
> popular?  Are there other's I have omitted?  Are there any free tools (I
> will check the CBT list in a moment)?  We are a z/OS 1.11 JES3 shop.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL CROSS-REFERENCE Utilities

[Ed Gould]

 Steve as usual is right. However before going out and buying anything, may I 
suggest you sit down with the application people and come up with some 
standards for JCL that you can live with.
This IS a starter list and you can discard what don't you want also add in 
as desired.
Step names
Proc names
Ds names
Symbolic use
One parameter per card ex dsname and unit etc etc 
Be consistent
All JCL be in one place
Etc etc etc

Above all be consistant and standardize.

This will make any program you decide on easier to use and produce meaningful 
output.
Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL CROSS-REFERENCE Utilities

[Steve Comstock]

On 10/5/2011 11:24 AM, Roberts, John J wrote:

My current client has long avoided any of the "modern" JCL enhancements.
For example, PROCs are very rare.  As are temporary datasets.

I am trying to upgrade some of the batch apps with PROC/JCLLIB/SET/INCLUDE/IF 
etc.

One of the impediments to the upgrade is the existence of custom JCL XREF tools.
For example, whereas before they may have coded DSN=X470.C100(+1), in the new 
scheme
they are likely to see DSN=&C100XDSN(+1) where&C100XDSN is a SET variable 
within an
INCLUDE member.  So I am betting that the homebrew XREF tools won't work.

So I think my replacement for this homebrew functionality will need to be a
commercial (COTS) package.

I am familiar with the various Windows-based tools for source analysis (Micro
Focus Modernization Workbench, EZSource, etc.).  But I think these are overkill
for my client's needs.

What is really needed is an inexpensive z/OS tool.  A bit of Googling turns up
JCL/Analyzer from CSI International, XREFplus from SEASOFT, JED from DCMSI, and
ASG-DOCU/TEXT from ASG.

So my questions for listers: which of these tools is a good value (compromise
between cost and functionality)?  And which is the most popular?  Are there 
other's
I have omitted?  Are there any free tools (I will check the CBT list in a 
moment)?
We are a z/OS 1.11 JES3 shop.

Thanks.

John



Ooooh. And then you'll need to train the JCL coders in how to use
all these 'new' features, right? Consider:

  http://www.trainersfriend.com/JCL_courses/B620descrpt.htm





--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html