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:
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
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
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
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-
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)
Tomorrow: lengthfield + parm (max 100 bytes) + padding to 102 bytes +
newlengthfield + newparm (max 4GiB ? :) )
This of course has the
The idea is that ALL receives at least:
lengthfield + parm (max 100 bytes) + padding to 102 bytes + newlengthfield
- and that the newlengthfield is either updated with a length value or is zero
by default.
I here assumes that the system add at least 4 zeroed bytes in appropriate
places - at
7 matches
Mail list logo
