Thank you all, I see some very interesting ideas. I will discuss them with my
colleague.
Best regards,
Natasa
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message
Mike Ross wrote:
>Flex/ES. Dongles. Fah. I've had sufficient experience with dongles to
implement
rule 1: If your business depends on it, crack it. It's guaranteed to stop
working - temporarily or permanently - sooner or later.
You're right. I HATE dongles. Dongles either stop working or getting
How can new programs determine if they received the new or the old
format, i.o.w. if they can/should process the data after byte 100 or not?
It's really quite simple Kees, the program should process exactly the
number of bytes that the 2-byte (halfword) length prefix says is
present, no more a
> The debate starts because of the following disclaimer in the IBM manual
>(MVS SYSTEMS COMMANDS) we see the following disclaimer
>
>- SNIP -
>Be careful when you use UPDATE. Updating an address space while a program
>in that address space is fetching a module can cause the fetch to fa
In , on
10/28/2009
at 03:44 PM, "Nuttall, Peter (P.)" said:
>Although ignorant in this field, I'm wondering why this
>approach wouldn't work (as noone is suggesting it):
>Today:lengthfield + parm (max 100 bytes)
Today's maximum is not 100 characters, because you can invoke utilities
fro
In <4ae89068.2050...@gabegold.com>, on 10/28/2009
at 02:41 PM, Gabe Goldberg said:
>The bureaucrats at the Justice Dept., the European Commission, and a
>trade group called CCIA are looking to take from IBM what their supposed
>"victim" could not earn in the free market.
The fact is that IB
Don't think it is that simple.
I know how the parmfield works today.
If I understand the proposed new parmfield correctly,
> > > Today:lengthfield + parm (max 100 bytes)
> > > Tomorrow: lengthfield + parm (max 100 bytes) + padding to 102
the first 102 bytes will remain unchanged and additiona
Thanks all for the good discussion. All the points mentioned are valid
(especially the caution about LNKLST UPDATE).
I don't think there is all that much complexity involved with using dynamic
LNKLST. But its true effectiveness is when you don't have a requirement
that old jobs use the new infor
There is of course a problem if You have a program that:
1. Expects parm from both the JCL PARM mechanism and from
common standard linkage/calls,
and
2. Receives a parm with a length field value of exactly 100,
and
3. Can't determine if the parm in reality is longer than
that or not (that is:
I have just closed a PMR with IBM on this subject.
We have a dynamic process using UPDATE JOBNAME=*. It's worked for many
years, but recently it failed big time, knocking out JES2.
The reason for the PMR was to get an explanation of DELAY= parameter on
the UPDATE statement. It is not properly do
This solution is of course only for the JCL PARM mechanism.
(The receiving program has of course to be aware of this to
be able to use it, but that is somehow the point of it.)
Regards,
Thomas Berg
__
Thomas Berg Specialist IT-U SWEDBANK
My startup command looks like this:
"D:\Program Files\RMF\pm390\ibmjava\jre\bin\javaw.exe" -jar gpm.jar
>>> Dennis McCarthy 10/28/2009 10:37 AM >>>
Hello Listers,
Does anyone know the string of options that should be passed when opening
the Reporter with the following command:
"C:\Program
No parm in JCL results in a parmfield with a lenghtfield of zeros.
L R3,0(R1)ADDRESS OF PARM.
LHR2,0(R3)LENGTH OF PARM.
LTR R2,R2 LENGTH ZERO?
BZEND ==> NO PARM.
Kees.
"Thomas Berg" wrote in message
news:...
> There
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mike Ross
> Sent: Wednesday, October 28, 2009 10:03 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Of interest to Developers
>
> On 28 Oct 2009 13:56:01 -0700, in bit.listserv.ibm-main yo
What is placed after the length field when it's zero ?
A S0C4 trap ? Or maybe some area which always is zero today ?
(Hope never dies... :) )
Regards,
Thomas Berg
__
Thomas Berg Specialist IT-U SWEDBANK
> -Ursprungligt meddelande
In , on 10/22/2009
at 08:59 AM, Arthur Gutowski said:
>John, thanks for the links. Also thanks to all who provided contact
>info. I had a recent "experience" with a dock station for my home
>machine that I want to "share" with Dell corporate and "consumer
>reports" sites. I used to think
The answer is: you don't know, so you can't and shouldn't assume anything.
It is not an 0C4 'trap', you should not reference storage of which you are not
sure that you can reference it.
Kees.
"Thomas Berg" wrote in message
news:...
> What is placed after the length field when it's zero ?
> A
Thanks Don,
Good to know No doubt I'll have cause to make use of that some time
in the future :-) ...
Kind regards,
Peter
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Don Leahy
Sent: 28 October 2009 17:10
To: IBM-MAIN@bama.ua.edu
The fullword is a standard plist, so the high bit is set as a end of list
indicator.
As I see, there is little to no need for a program to need to know whether
the parm was generated by PARM or PARMX. If the length is over 100, it came
from PARMX. If it was less than 101, then either PARM or PARMX
On 29 Oct 2009 03:17:25 -0700, in bit.listserv.ibm-main you wrote:
>>How can new programs determine if they received the new or the old
>>format, i.o.w. if they can/should process the data after byte 100 or not?
>
>It's really quite simple Kees, the program should process exactly the
>number of
The point is: this is a very old interface, there could
well be that it's always have the same content. If You know
the code behind You could verify that.
Regards,
Thomas Berg
__
Thomas Berg Specialist IT-U SWEDBANK
> -Ursprungligt meddelan
"Clark Morris" wrote in message
news:...
> On 29 Oct 2009 03:17:25 -0700, in bit.listserv.ibm-main you wrote:
>
> >>How can new programs determine if they received the new or the old
> >>format, i.o.w. if they can/should process the data after byte 100 or
not?
> >
> >It's really quite simple K
We are currently considering hardware encryption for our off-site copies of DR
volume backups and HSM.COPY.**.
Question - Can the HSM.Backtape and ML2 tapes be unencrypted while the off-site
HSM.COPY.** tapes are encrypted?
Is anyone doing this?
Thank You,
Dave O'Brien
NIH Contractor
---
The point is: if IBM has not documented something, you cannot rely on it. It
might be true for many years and can suddenly change with a new release. IBM
can even legitimitely change the code you just checked how it works.
Kees.
"Thomas Berg" wrote in message
news:...
> The point is: this is
The point is: we are discussing a change of the code
for eventual forwarding to IBM.
If IBM accept it, there is no problem (with future changes).
Regards,
Thomas Berg
__
Thomas Berg Specialist IT-U SWEDBANK
> -Ursprungligt meddelande-
>
O'Brien, David W. (NIH/CIT) [C] pisze:
We are currently considering hardware encryption for our off-site copies of DR
volume backups and HSM.COPY.**.
Question - Can the HSM.Backtape and ML2 tapes be unencrypted while the off-site
HSM.COPY.** tapes are encrypted?
Yes.
Encryption in STK drives
Keith E. Moe wrote:
"
...
Many programs, such as ISV products, would likely be modified to query
the existence of the extended PARM and use it if present and
otherwise fall back to the current PARM field. This would allow them to
exploit the capability quickly and allow customers to convert their
Can the HSM.Backtape and ML2 tapes be unencrypted while the off-site
HSM.COPY.** tapes are encrypted?
>From what RS indicated, it sounds like the T9840D device is either encrypt
or not (I don't know what those devices are like) which would mean that
you'd have to segregate allocation with USE
In <4ae0666f.8489.00d...@joann.com>, on 10/22/2009
at 02:04 PM, Scott Rowe said:
>When it comes to PCs, I just order the parts and build it myself, it
>certainly not rocket science. Any of this August group who have any
>hardware knowledge should be able to build a PC easily, and that way you
On Wed, 28 Oct 2009 14:30:47 -0500, Ward, Mike S wrote:
>Hello all, can someone point me to a manual or command that will show
>what SVCs are actually in use? I looking in ieasvcxx, but that only
>shows what user/vendor supplied SVCs are used. Thanks in advance.
If you have SYSVIEW, try the SVCT
Hi Jack,
Yes, the T9840D has an encryption feature. We control tape allocation via STK
Tapereq parameters so Userunittable does not come into play nor does SMS. This
was strictly a question of whether or not the HSM Primary copy could be
unencrypted while the Duplex copy would be encrypted.
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.)
> Sent: Thursday, October 29, 2009 9:07 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: OFF TOPIC - DELL CUSTOMER SUPPORT
> Every time someone says "I don't beli
Quick start Video tutorial (October 28, 2009).
The Video time length is more than 40 minutes.
The video demonstrates how to install, define and run emulated 3390 disks
and emulated 3490 tapes.
I create the video and store it in Youtube. Because of Youtube limitation, the
video file is divided
You can use TSO ISRDDN.
2009/10/28 Ward, Mike S
> Hello all, can someone point me to a manual or command that will show
> what SVCs are actually in use? I looking in ieasvcxx, but that only
> shows what user/vendor supplied SVCs are used. Thanks in advance.
> ==
> This
Without chasing though control blocks? Are you sure your not
confusing it with ISRDDN's big brother TASID?
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programmin
On Thu, 29 Oct 2009 15:48:24 +0100, Vernooij, CP - SPLXM wrote:
>
>This is not fully failsafe: the parm was documented as being limited to
>100 bytes. So easy programmering could initialize a 100 byte area to
The PARM is not documented as being limited to 100 bytes. Rexx
Language can pass PARMS o
FYI. There is an error in the SMF record layout for Type 42-10 SMS
Volume selection failure. Below is the information sent to IBM for
correction.
--> signature = 6 lines follows <--
Neil Duffee, Joe SysProg, U d'Ottawa, Ottawa, Ont, Canada
telephone:1 613 562 5800 x4585
> The PARM is not documented as being limited to 100 bytes. Rexx
> Language can pass PARMS of up to 32767 bytes; Assembly Language
> up to 65535. 100 is merely a restriction built into Job Control
> Language, and documented in the JCL manual.
In other words, PARM *is* documented as being limited
On Thu, 29 Oct 2009 20:59:45 +, Gainsford, Allen wrote:
>
>If a program is only intended to be called from JCL, and it does
>not cope with being called with longer parameters, then the program
>is not broken. It is following the rules, and functioning as
>intended. If some clever person calls
All,
The proposal previously set forth is interesting, but I would like to put
forward an alternative proposal.
For a short PARM= value (compatibility mode), R1 -> fullword address of
PARM= info, consisting of a 2-byte length prefix (value 0..100) followed by
a string buffer not exceeding 1
On Thu, 29 Oct 2009 17:28:44 -0400, John P. Baker wrote:
>
>For a short PARM= value (compatibility mode), R1 -> fullword address of
>PARM= info, consisting of a 2-byte length prefix (value 0..100) followed by
>a string buffer not exceeding 100 bytes.
>
>For a long PARM= value, R1 -> fullword addres
Shmuel Metz (Seymour J.) wrote:
In case you didn't notice this, you might want to look into it.
I saw the original thread, but as far as I can tell, I couldn't
qualify,and in any case it's a lot of money. I'd rather spend my
time on Hercules and MVS (and I just discovered a 7094
simulator, c
> Likewise, if the "clever person" calls the program from JCL
> with the (proposed) 10,000-character PARM and the program crashes,
> it is the caller who is at fault, neither the program nor the
> JCL converter. But I have trouble with "intended". A careful
> programmer should allow for the possi
Jonathan Swift's original horrific--albeit satirical--modest proposal of 1729
evoked untoward responses too.
This time the OP, who is certainly capable of mixed, not wholly serious
intentions, may well be enjoying the intemperate responses to his proposal as
much as Swift did the outrage t
Allan,
I have successfully performed this type of workload transfer a number of times
using ABARS with and without Mainstar's Backup and Recovery Manager (BRM)
Suite. Using BRM to track the backups and facilitate the restores makes the
job much easier and less error prone. I would be happy to di
My desire is that programs should be designed to gracefully refuse to be
abused, otherwise I tend to classify them as broken.
For example, the huge number of security problems in the Windows world is
caused by buffer overruns. The user (albeit a malicious user) usually
constructs some form of inva
I think that would "break" many programs. Many standard utilities,
compilers, etc. expect to invoked from either JCL where there is only one
parm or dynamically called with one or more parms. Off the top of my head I
can't remember for format of the second parm other than it is used to
dynamically
I will be out of the office starting Fri 30/10/2009 and will not return
until Mon 02/11/2009.
I will respond to your message when I return. For any urgent issues please
contact Quentin Jansen.
--
For IBM-MAIN subscribe / signoff
>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.
In many countries, if you actually follow that advice the vendor could
successfully sue your business into o
At 13:41 +0800 on 10/29/2009, David Stephens wrote about Re: What
SVCs are in use?:
Good point Robert. SVC109 is for Type 3, 116 for type 1, 122 for type 2,
137 for type 6.
I always thought that there was another SVC table pointed to by the SVC
table entries for SVC 109, 116 etc., but can't se
50 matches
Mail list logo
