I am using TRSMAIN to unpack into a pds. The Tresed file is quit large and
the job abends with av37-4 on a temporary dataset that is allocated by
TRAMAIN (DD-SYS3). Preallacting the dataset cause TRSMAIN to try to
allocate the next dataset (and abend again). I also tried to change the
alloc00
On Mon, 2 Nov 2009 11:04:22 +0200, Itschak Mugzach wrote:
I am using TRSMAIN to unpack into a pds. The Tresed file is quit large and
the job abends with av37-4 on a temporary dataset that is allocated by
TRAMAIN (DD-SYS3). Preallacting the dataset cause TRSMAIN to try to
allocate the next
Thanks Norbert. This is it...
Itschak
On Mon, Nov 2, 2009 at 11:34 AM, Norbert Friemel nf.ibmm...@web.de wrote:
On Mon, 2 Nov 2009 11:04:22 +0200, Itschak Mugzach wrote:
I am using TRSMAIN to unpack into a pds. The Tresed file is quit large and
the job abends with av37-4 on a temporary
Does anyone knows an alternative to the mainframe product known as QuickRef?
ITschak
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Itschak Mugzach schrieb:
Does anyone knows an alternative to the mainframe product known as QuickRef?
I' currently working on a Help-System that will hopefully be released
Q1 next year (most of the work is done - I'm currently cleaning up some
things, implement licesnsing stuff, design the
If the current JCL PARM format change from HW + 0-100 bytes
to HW + 100 bytes + FW for the new long parm + 0-??? bytes long parm,
are there any backward compatibility problems ?
Regards,
Thomas Berg
__
Thomas Berg Specialist IT-U SWEDBANK
If you have CAs Datacom you can look it up using dbutlty
mace
On Fri, Oct 30, 2009 at 10:24 AM, Mark Zelden mark.zel...@zurichna.comwrote:
I know how you do it with TASID. I was asking how you do it
with ISRDDN as you suggested.
Regards,
Mark
--
Mark Zelden
Sr. Software and Systems
We are currently developing the implementation of EMV ICSF. We wants to hear
about any experience managing ARQC cryptograms and ARPC.
Thanks in advance.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send
On Mon, 2 Nov 2009 13:40:44 +0100 Thomas Berg thomas.b...@swedbank.se wrote:
:If the current JCL PARM format change from HW + 0-100 bytes
:to HW + 100 bytes + FW for the new long parm + 0-??? bytes long parm,
:are there any backward compatibility problems ?
Not at all.
Would require a CVT bit
Certainly a very strong argument against ever performing UPDATE=*. I
appreciate the clarification, but certainly don't like the answer.
Without some idea about what z/OS services or subsystems might make
unwarranted assumptions about old lnklst control structures, the user or
other vendors are
Thank you, Bill and Chris, for explaining the not-...@#$%ing-obvious. It
would appear that some of the application programmers whom I've been
admonishing to be more explicit than A processing error has occurred
have been advising the FTP developers in their considerable spare time
on how to handle
Chris
Thanks for your information. After reading it seems to be a little bit clearer.
I didn't know that relation between vipadefine and vipabackup in that way you
described. So it's ok with the definition of vipabackup in my second system.
After reading again the definitions in the original
On Mon, Nov 2, 2009 at 10:05 AM, Miller, Pat pat.mil...@trs.state.tx.uswrote:
It would appear that some of the application programmers whom I've been
admonishing to be more explicit than A processing error has occurred
have been advising the FTP developers in their considerable spare time
on
I have this note on AMATERSE:
Sometimes TRSMAIN today (Sep 2007) will fail with a space error on the
intermediate work file.
An unsupported undocumented option for the current TRSMAIN is adding the
TMPSPACE DD. This usually will let you terse PDSE or other things that
mess up it's
On Mon, 2 Nov 2009 12:13:03 +0200, Itschak Mugzach
imugz...@gmail.com wrote:
Does anyone knows an alternative to the mainframe product known as
QuickRef?
ITschak
Itschak,
Have you seen IBM's 'LOOKAT' facility?
http://www-03.ibm.com/systems/z/os/zos/bkserv/lookat/
There's a
On Fri, 30 Oct 2009 11:24:55 -0600, Joe Pfeiffer
pfeif...@cs.nmsu.edu wrote:
Unicode has a lot of inertia at this point, and 7-bit ASCII has more. I
can reasonably expect both of them to last long after my death, and docs
and conversion programs until civilization collapses to the point
On 31 Oct 2009 09:37:18 -0700, Patrick Scheible k...@zipcon.net
wrote:
All the characters from the several versions of EBCDIC are in Unicode.
It should be simple enough to map them from EBCDIC order to Unicode
order, and back, if necessary.
Sort order would be different - will that matter?
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Howard Brazee
Sent: Monday, November 02, 2009 10:01 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: big iron mainframe vs. x86 servers
On 31 Oct 2009 09:37:18 -0700, Patrick Scheible
Department of dumb hobbyist questions. I have an Application Starterpak 3000 -
call it a Multiprise 2000-2xx, that's close enough for government work.
I'm blowing it out and starting afresh. I've pulled all the old 9GB internal
DASD and replaced it with shiny new (well old, new to me) 18GB DASD.
If BookManager is available on the mainframe, a custom bookshelf can be created
containing all of the messages and codes manuals (e.g. the ISPF messages and
codes manual and the COBOL messages and codes manual, etc). A user then only
has to search one bookshelf for any message or code they
On Sat, 31 Oct 2009 00:33:10 -0400, Robert A. Rosenberg wrote:
At 17:40 -0500 on 10/30/2009, Paul Gilmartin wrote about Re: An
Alternative Modest PARM Proposal:
Therefore, you should understand very well why this won't work.
Such utilities will misinterpret the Long Parm as a DDN override
list.
Mike Ross wrote:
snip
I can't find ANY doc on restoring the preinstalled system (OS/390 2.4) from tape
(if anyone can point me to some doc specific to this preinstall it would be a
Good Thing), and it's a LONG time since I've done this. So a dumb basic question
for starters: with internal DASD,
On 29 Oct 2009 21:32:34 -0700, timothy.sipp...@us.ibm.com (Timothy Sipples)
wrote:
I've had sufficient experience with dongles to implement
rule 1: If your business depends on it, crack it.
I disagree, and I think that's supremely bad advice. Hopefully you were
joking.
I was not. I've known of
Question... what does Lookat not do that QuickRef does ??
From:
Dana dmit...@shazam.net
To:
IBM-MAIN@bama.ua.edu
Date:
11/02/2009 09:56 AM
Subject:
Re: Alternatives to QuickRef?
Sent by:
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
On Mon, 2 Nov 2009 12:13:03 +0200, Itschak Mugzach
On 2 Nov 2009 06:35:21 -0800, in bit.listserv.ibm-main you wrote:
Certainly a very strong argument against ever performing UPDATE=*. I
appreciate the clarification, but certainly don't like the answer.
Without some idea about what z/OS services or subsystems might make
unwarranted assumptions
On Mon, 2 Nov 2009 13:40:44 +0100, Thomas Berg wrote:
If the current JCL PARM format change from HW + 0-100 bytes
to HW + 100 bytes + FW for the new long parm + 0-??? bytes long parm,
are there any backward compatibility problems ?
There would be a lateral compatibility problem, in that the
parm
On Mon, 2 Nov 2009 10:50:06 -0600 Paul Gilmartin paulgboul...@aim.com wrote:
:On Mon, 2 Nov 2009 13:40:44 +0100, Thomas Berg wrote:
:If the current JCL PARM format change from HW + 0-100 bytes
:to HW + 100 bytes + FW for the new long parm + 0-??? bytes long parm,
:are there any backward
Have you seen IBM's 'LOOKAT' facility?
http://www-03.ibm.com/systems/z/os/zos/bkserv/lookat/
There's a downloadable package for running it under TSO/E. I've used it in
the past when working at sites that do not have QW and it's a viable
substitute.
Only for IBM products.
Unless things
On 2 Nov 2009 08:37:54 -0800, in bit.listserv.ibm-main you wrote:
Mike Ross wrote:
snip
I can't find ANY doc on restoring the preinstalled system (OS/390 2.4) from
tape
(if anyone can point me to some doc specific to this preinstall it would be a
Good Thing), and it's a LONG time since I've
Pat
What you may be suffering from is an expectation that IBM documentation is
going to be comprehensive when it comes to matters IP and related
protocols. It isn't and the folk behind IBM's software in the realm of IP and
related protocols have never considered that they should offer a
But obviously not a *backward* compatibility problem ?
And the main problem here, as I have understood the
discussion, is the limit of 100 bytes through JCL PARM.
And that is sort of another format as I see it.
As the problem is (old?) programs that cannot cope with
longer parms than 100 bytes,
Question... what does Lookat not do that QuickRef does ??
Other vendor's messages, for one.
-
Too busy driving to stop for gas!
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
On Mon, 02 Nov 2009 09:45:34 -0700, Joe Pfeiffer
pfeif...@cs.nmsu.edu wrote:
Unicode has a lot of inertia at this point, and 7-bit ASCII has more. I
can reasonably expect both of them to last long after my death, and docs
and conversion programs until civilization collapses to the point
On 02 Nov 2009 09:08:18 -0800, Patrick Scheible k...@zipcon.net
wrote:
Sort order would be different - will that matter?
Yes, there are probably some programs for which it does. Those that
do will have to convert Unicode to EBCDIC and probably convert back
again to do their final output. Or
On 2 Nov 2009 09:19:45 -0800, thomas.b...@swedbank.se (Thomas Berg)
wrote:
As the problem is (old?) programs that cannot cope with
longer parms than 100 bytes, among them IBM module apparently,
that's the problem that needs to be solved.
So we cannot avoid a somewhat ugly change of the JCL
On Mon, 2 Nov 2009 18:59:19 +0200, Binyamin Dissen wrote:
On Mon, 2 Nov 2009 10:50:06 -0600 Paul Gilmartin paulgboul...@aim.com wrote:
:On Mon, 2 Nov 2009 13:40:44 +0100, Thomas Berg wrote:
:If the current JCL PARM format change from HW + 0-100 bytes
:to HW + 100 bytes + FW for the new long
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Thomas Berg
Sent: Monday, November 02, 2009 11:15 AM
To: IBM-MAIN@bama.ua.edu
Subject: SV: SV: An Alternative Modest PARM Proposal
But obviously not a *backward* compatibility
Okay, I have been reading the manuals and still cannot find the right info.
I have a VTS which is hooked up to my Specialist. In that guy I have backend
tapes for the B20.
Where can I go to see HOW MANY backend tapes I have used? And how many I have
not used.
Is there a way from the z/OS
On Mon, 2 Nov 2009 18:14:38 +0100, Thomas Berg wrote:
But obviously not a *backward* compatibility problem ?
And the main problem here, as I have understood the
discussion, is the limit of 100 bytes through JCL PARM.
And that is sort of another format as I see it.
As the problem is (old?)
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Lizette Koehler
Sent: Monday, November 02, 2009 11:42 AM
To: IBM-MAIN@bama.ua.edu
Subject: How to determine number of back end tapes in a B20
Okay, I have been reading the manuals
-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] För Tom Marchant
Skickat: den 2 november 2009 18:42
Till: IBM-MAIN@bama.ua.edu
Ämne: Re: SV: SV: An Alternative Modest PARM Proposal
On Mon, 2 Nov 2009 18:14:38 +0100, Thomas Berg wrote:
Yes, other vendor's messages for one.I should have added a disclaimer to
my statement about that.Another is that QW can dispense lots of other
goodies such as utility control statement formats, commands, REXX and clist
etc. And it handles multiple releases of info much better than
-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] För McKown, John
Skickat: den 2 november 2009 18:38
Till: IBM-MAIN@bama.ua.edu
Ämne: Re: SV: An Alternative Modest PARM Proposal
-Original Message-
From: IBM Mainframe
On Mon, 2 Nov 2009 11:38:25 -0600, McKown, John wrote:
How about just agreeing that the HW pointed to my R1 can range in value from 0
to +32,767.
In fact, at least one IBM program (I just tested it) works quite well with
a PARM string length of 65,635 in the HW.
And, in the new JCL PARMX
D SMS,LIB(libname),DETAIL
CBR1110I OAM LIBRARY STATUS: 153
TAPE LIB DEVICETOT ONL AVL TOTAL EMPTY SCRTCH ON OP
LIBRARY TYP TYPE DRV DRV DRV SLOTS SLOTS VOLS
IBMVTS41 VL 3494-L10 128 128 127 4166 6 24291 Y Y
On Mon, 2 Nov 2009 18:57:49 +0100, Thomas Berg wrote:
Don't we then have a usage problem here ? I'm thinking of thousands
of sites with many more programmers and operators etc. that have
to deal with - now - two forms of parms. I'm thinking of some sort of caos...
And don't we still have the
-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] För Paul Gilmartin
Skickat: den 2 november 2009 19:23
Till: IBM-MAIN@bama.ua.edu
Ämne: Re: An Alternative Modest PARM Proposal
On Mon, 2 Nov 2009 18:57:49 +0100, Thomas Berg wrote:
Hello,
I've to share a TS7740 and a TS3300 with 4 lpars, 2 lpars from firm1 and other
2 from firm2. None is sysplex.
Virtual and native volumes volsers are different from both firms and also
Stacked volumes are different, so different stack volume pools.
Questions:
1) For each firm I want
On 10/28/2009 at 6:44 AM, in message 4ae83c91.4080...@trainersfriend.com,
Steve Comstock st...@trainersfriend.com wrote:
Frank Swarbrick wrote:
By the by, I added CSSLIB some time ago, but I can't for the life of me
remember why. Any idea?
These are z/OS UNIX callable services.
Turns out
On Mon, 2 Nov 2009 19:45:43 +0100, Thomas Berg wrote:
Well, the caos is not primarily feared based on API format. I was thinking
of Job JCLs that production planners, those who restart and corrects jobs,
application programmers/designers etc; all those who deals with parms that
have application
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin
Sent: Monday, November 02, 2009 1:56 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: SV: An Alternative Modest PARM Proposal
snip
I might even advocate a new JCL command,
On 2 Nov 2009 10:23:59 -0800, in bit.listserv.ibm-main you wrote:
On Mon, 2 Nov 2009 18:57:49 +0100, Thomas Berg wrote:
Don't we then have a usage problem here ? I'm thinking of thousands
of sites with many more programmers and operators etc. that have
to deal with - now - two forms of parms.
-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] För Paul Gilmartin
Skickat: den 2 november 2009 20:56
Till: IBM-MAIN@bama.ua.edu
Ämne: Re: SV: An Alternative Modest PARM Proposal
On Mon, 2 Nov 2009 19:45:43 +0100, Thomas Berg wrote:
On Mon, 2 Nov 2009 14:02:26 -0600, McKown, John wrote:
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin
I might even advocate a new JCL command, //L EXECU PGM=...,
where EXECU invokes the program in the unauthorized
snip
There is NO REASON to send a Long Parm to these IBM utilities
Of course there is. It ignores, e.g., IBM compilers.
--unsnip---
IIRC, the IBM compilers will also accept a *PROCESS
On Mon, 2 Nov 2009 21:16:42 +0100, Thomas Berg wrote:
*BUT*, we still we have the problem of backward incompatibility
regardless of the input format...
Not if the PARM is stored in memory the same way it is today: A fullword
parameter address with the high order bit set to 1. That word points
I would prefer to be able to pass a long parm to authorized programs.
Authorized programs should be well written to check everything it receives,
otherwise it is a security risk. In other words, an authorized program
should always be written to prevent any detrimental activity, malicious or
On Mon, 2 Nov 2009 21:16:42 +0100, Thomas Berg wrote:
If we really go the new syntax road, I liked the suggestion,
by someone I don't remember for the moment, that we introduce
a new JCL operand:
// PARM '...'
I like that partly beacuse of possibility to have a concatenate
function like:
//
All,
Today, as one of the directives in httpd.conf on my 1.10 system I have:
Exec/uCMDB/* /u/HP/Discovery/cgi-bin/*
Directory /u/HP/Discovery/cgi-bin/ contains REXX execs that also reside
in a standard MVS PDS dataset.
Is it possible using the MVSDS service to point
On Mon, 2 Nov 2009 14:47:12 -0600, Rick Fochtman wrote:
snip
There is NO REASON to send a Long Parm to these IBM utilities
Of course there is. It ignores, e.g., IBM compilers.
--unsnip---
IIRC, the
On Mon, 2 Nov 2009 11:32:34 -0600 Tom Marchant m42tom-ibmm...@yahoo.com
wrote:
:On Mon, 2 Nov 2009 18:59:19 +0200, Binyamin Dissen wrote:
:On Mon, 2 Nov 2009 10:50:06 -0600 Paul Gilmartin paulgboul...@aim.com
wrote:
::On Mon, 2 Nov 2009 13:40:44 +0100, Thomas Berg wrote:
::If the current JCL
| Of course there is. It ignores, e.g., IBM compilers.
|
| --unsnip---
|
| IIRC, the IBM compilers will also accept a *PROCESS
| statement that can be as long as necessary.
You don't remember correctly. Some process statements are limiteds to a proper
At 18:14 +0100 on 11/02/2009, Thomas Berg wrote about SV: SV: An
Alternative Modest PARM Proposal:
As the problem is (old?) programs that cannot cope with
longer parms than 100 bytes, among them IBM module apparently,
that's the problem that needs to be solved.
Not exactly on the IBM
At 11:26 -0600 on 11/01/2009, Rick Fochtman wrote about Re: An
Alternative Modest PARM Proposal:
-snip-
There is NO REASON to send a Long Parm to these IBM utilities so
this potential glitch can easily be handled by a new PARMLIB
At 12:58 -0500 on 11/01/2009, Shmuel Metz (Seymour J.) wrote about
Re: An Alternative Modest PARM Proposal:
There is NO REASON to send a Long Parm to these IBM utilities
Of course there is. It ignores, e.g., IBM compilers.
When CALLED as opposed to JCL LAUNCHED, do these IBM Compilers
PW RESET
The information contained in this message, and any attachments thereto,
is intended solely for the use of the addressee(s) and may contain
confidential and/or privileged material. Any review, retransmission,
pw reset
Clayton Buck
Lead System Performance/Capacity Planning Analyst
UniGroup, Inc.
636-349-2859
The information contained in this message, and any attachments thereto,
is intended solely for the use of the
My apologies if this has been discussed in the past, but as someone that
groups his IBM-Main inbox by Subject I want to point out the following:
http://www.trilithium.com/johan/2005/06/re-outlook/
As far as I'm concerned everyone has the right to use whatever reply
prefix they want and I don't
MVS command: d sms,lib(vtsname),detail
CBR1110I OAM library status: 963
TAPE LIB DEVICETOT ONL AVL TOTAL EMPTY SCRTCH ON OP
LIBRARY TYP TYPE DRV DRV DRV SLOTS SLOTS VOLS
STOOGES VL 3494-L10 240 240 222 1803806 76719 Y Y
On Mon, 2 Nov 2009 16:58:37 -0500, Robert A. Rosenberg wrote:
At 12:58 -0500 on 11/01/2009, Shmuel Metz (Seymour J.) wrote about
Re: An Alternative Modest PARM Proposal:
There is NO REASON to send a Long Parm to these IBM utilities
Of course there is. It ignores, e.g., IBM compilers.
When
On Mon, 2 Nov 2009 23:50:17 +0200, Binyamin Dissen wrote:
:The suffix does not violate compatibility. A CVT bit could indicate the
:support for the suffix.
:So that a program that works with a long parm today, such as the Assembler,
:would have to be modified to test the CVT and look in a new
On 2 Nov 2009 08:37:54 -0800, ee...@us.ibm.com (John Eells) wrote:
Mike Ross wrote:
snip
I can't find ANY doc on restoring the preinstalled system (OS/390 2.4) from
tape
(if anyone can point me to some doc specific to this preinstall it would be a
Good Thing), and it's a LONG time since I've
Dear listers
I am interested in implementing some kind of session level encryption for SNA
data (LU 6.2 \ Enterprise Extender) but do not have a crypto processor.
Is it possible to do Session level encryption. IPSEC still far away for us.
regards
Munif
You and I have diametrically opposed perspectives of compatibility.
To me, compatibility means the facility to call a program from JCL
with a long PARM presenting exactly the same interface as today when
it's called from other languages (such as Rexx), and requiring
modification neither
74 matches
Mail list logo
