Prev: S0C4 x'4' abend while reading VSAM KSDS file
Next: COBOL: Don`t Call It a Comeback
From: Pete Dashwood on 18 Jul 2008 10:23


"Roger While" <simrw(a)sim-basis.de> wrote in message
news:g5q2vs$8ov$02$1(a)news.t-online.com...
>
> "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> schrieb im
> Newsbeitrag news:6eahskF64pbgU1(a)mid.individual.net...
>> Fujitsu extends COBOL with the following intrinsic function:
>>
>> STORED-CHAR-LENGTH Function
>>
>> This function returns the length of the effective characters (without
>> training blanks)
>> contained in argument-1.
>> The STORED-CHAR-LENGTH function is specific to Win32, Sun and Linux.
>> For details about how to use the examples, refer to "STORED-CHAR-LENG
>> Function"
>> in the "Syntax Samples".
>
> OpenCOBOL also has this function.
>
> Roger

Excellent! Good job, Roger.

Is OC going to be the first implementation of the 2002 standard?

When is it likely to be RTM?

Pete.
--
"I used to write COBOL...now I can do anything."
>


From: William M. Klein on 18 Jul 2008 17:54

"Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message
news:6eahskF64pbgU1(a)mid.individual.net...
<snip>
> I'm inclined to agree with Robert that it must be possible to write such a
> function easily in COBOL and put it in the same library as the other intrinsic
> functions that ARE available with VSE. Try having a chat to your friendly
> neighbourhood systems programmer... if the guy is good he might be very happy
> to to indulge you. I'd be surprised if IBM don't allow maintenance of these
> libraries. (You're not changing any existing functionality, just extending
> it....now, where have we heard that before...? Oh yeah, standard practice with
> OO...:-)
>
I don't know of ANY compiler that allows one to add "user-defined' INTRINISC
functions. Some (but not any IBM mainframe one) do allow for user-defined
funcitons, but they have syntaxtic differences from intrinsic functions (just a
the '02 Standard would expect).

Actually, I think that IBM mainframe programmers COULD (if they really wanted
to) create pseduo-intrinsic functions. If you created an "EXIT" - see:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGYVA002/APPENDIX1.4

routine, you could create a CALLed subroutine that returned a "trimmed" value in
the RETURNED field.

However, that would be SO much work (for such little return), I find it pretty
hard to believe that anyone would do it.

--
Bill Klein
wmklein <at> ix.netcom.com


From: Pete Dashwood on 19 Jul 2008 01:01


"William M. Klein" <wmklein(a)nospam.netcom.com> wrote in message
news:ci8gk.255768$Ev5.111102(a)fe09.news.easynews.com...
>
> "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message
> news:6eahskF64pbgU1(a)mid.individual.net...
> <snip>
>> I'm inclined to agree with Robert that it must be possible to write such
>> a function easily in COBOL and put it in the same library as the other
>> intrinsic functions that ARE available with VSE. Try having a chat to
>> your friendly neighbourhood systems programmer... if the guy is good he
>> might be very happy to to indulge you. I'd be surprised if IBM don't
>> allow maintenance of these libraries. (You're not changing any existing
>> functionality, just extending it....now, where have we heard that
>> before...? Oh yeah, standard practice with OO...:-)
>>
> I don't know of ANY compiler that allows one to add "user-defined'
> INTRINISC functions. Some (but not any IBM mainframe one) do allow for
> user-defined funcitons, but they have syntaxtic differences from intrinsic
> functions (just a the '02 Standard would expect).

My comments were based on the hypothetical assumption that it was absolutely
necessary to do it, not the real world practicalities where it simply isn't.
:-)

It is sometimes surprising the things that sysprogs will do if they are
bored... :-)

>
> Actually, I think that IBM mainframe programmers COULD (if they really
> wanted to) create pseduo-intrinsic functions. If you created an "EXIT" -
> see:
>
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGYVA002/APPENDIX1.4
>
> routine, you could create a CALLed subroutine that returned a "trimmed"
> value in the RETURNED field.
>
> However, that would be SO much work (for such little return), I find it
> pretty hard to believe that anyone would do it.

Fair comment, Bill.

There are problems with using CALL as opposed to an intrinsic because it is
less flexible, and has to be resolved before it can be used in an
expression.

However, suppose, just as an academic exercise, you HAD to do it? (My
comments were based on that assumption)

The fact is that the compiler uses a library of intrinsic functions, and
connects them into object code by SOME mechanism. (We could speculate
whether it is inline or based on weak EXTERNs... doesn't really matter. Some
investigation would determine how it worked. Once the way it works is
determined, it shouldn't be hard to add another function to it... :-)

Having patched compilers in the past to do things they were never designed
to do, I would find this an interesting exercise. You might think of it as
just another (albeit, "unoffical") PTF... :-) If I were Frank, I'd certainly
talk to the local sysprog. Over a cup of coffee it might become a useful
site function.

OR, I guess one COULD go to SHARE and suggest it be included by IBM, then
wait indefinitely for it... :-)

P.S. I am not entirely serious about this...

Pete.
--
"I used to write COBOL...now I can do anything."



From: Frank Swarbrick on 19 Jul 2008 13:05
>>> On 7/17/2008 at 9:44 PM, in message
<6eahskF64pbgU1(a)mid.individual.net>,
Pete Dashwood<dashwood(a)removethis.enternet.co.nz> wrote:
> Fujitsu extends COBOL with the following intrinsic function:
>
> STORED-CHAR-LENGTH Function
>
> This function returns the length of the effective characters (without
> training blanks)
> contained in argument-1.
> The STORED-CHAR-LENGTH function is specific to Win32, Sun and Linux.
> For details about how to use the examples, refer to "STORED-CHAR-LENG
> Function"
> in the "Syntax Samples".
>
> Format
> FUNCTION STORED-CHAR-LENGTH (argument-1)
>
> Argument
> 1. Argument-1 must be alphanumeric or national characters. It must not be

> a
> group item. (It can be 01 with a picture... Pete)
> 2. Argument-1 must consist of one or more characters.
>
> Function Value
> 1. The function value is the number of character positions of the
> effective
> characters contained in argument-1.
> 2. When argument-1 is the alphanumeric class, the function value
> indicates
> the
> number of alphanumeric character positions of the effective characters.
> 3. When argument-1 is the national class, the function value indicates
> the
> number
> of national character positions of the effective characters.
> 4. The characters stored in argument-1 must follow the encoding forms
> dictated by
> the class of argument-1. Otherwise, the result is undefined.
>
> Function Type
> The function type is integer.
>
> Although it isn't clear above, I have found from extensive use of this
> function (it is very useful...) that the number it returns is the
> ordinal
> position of the last non-blank character in the string, so embedded
> spaces
> (any number) are fine and get counted.
>
> I'm inclined to agree with Robert that it must be possible to write such
> a
> function easily in COBOL and put it in the same library as the other
> intrinsic functions that ARE available with VSE. Try having a chat to
> your
> friendly neighbourhood systems programmer... if the guy is good he might
> be
> very happy to to indulge you. I'd be surprised if IBM don't allow
> maintenance of these libraries. (You're not changing any existing
> functionality, just extending it....now, where have we heard that
> before...?

I've seen no indication that this is possible, and even if it were I doubt
my system programmers would touch it with a 100 foot pole. Though if it
were possible I'd try to give it a shot. But it's very unlikely.

>
> Here's another idea :-) Why not write your function/module/whatever then
> replace one of the unused intrinsics with it (say COS...) if there
> really is
> no way to add to the compiler's function library... (no, Frank, I was
> joking...:-))

No idea how to do this either, but I'm sure something so unsupported would
never be allowed in production.

Frank

From: Pete Dashwood on 19 Jul 2008 21:14


"Frank Swarbrick" <Frank.Swarbrick(a)efirstbank.com> wrote in message
news:4881CA85.6F0F.0085.0(a)efirstbank.com...
>>>> On 7/17/2008 at 9:44 PM, in message
> <6eahskF64pbgU1(a)mid.individual.net>,
> Pete Dashwood<dashwood(a)removethis.enternet.co.nz> wrote:
>> Fujitsu extends COBOL with the following intrinsic function:
>>
>> STORED-CHAR-LENGTH Function
>>
>> This function returns the length of the effective characters (without
>> training blanks)
>> contained in argument-1.
>> The STORED-CHAR-LENGTH function is specific to Win32, Sun and Linux.
>> For details about how to use the examples, refer to "STORED-CHAR-LENG
>> Function"
>> in the "Syntax Samples".
>>
>> Format
>> FUNCTION STORED-CHAR-LENGTH (argument-1)
>>
>> Argument
>> 1. Argument-1 must be alphanumeric or national characters. It must not be
>
>> a
>> group item. (It can be 01 with a picture... Pete)
>> 2. Argument-1 must consist of one or more characters.
>>
>> Function Value
>> 1. The function value is the number of character positions of the
>> effective
>> characters contained in argument-1.
>> 2. When argument-1 is the alphanumeric class, the function value
>> indicates
>> the
>> number of alphanumeric character positions of the effective characters.
>> 3. When argument-1 is the national class, the function value indicates
>> the
>> number
>> of national character positions of the effective characters.
>> 4. The characters stored in argument-1 must follow the encoding forms
>> dictated by
>> the class of argument-1. Otherwise, the result is undefined.
>>
>> Function Type
>> The function type is integer.
>>
>> Although it isn't clear above, I have found from extensive use of this
>> function (it is very useful...) that the number it returns is the
>> ordinal
>> position of the last non-blank character in the string, so embedded
>> spaces
>> (any number) are fine and get counted.
>>
>> I'm inclined to agree with Robert that it must be possible to write such
>> a
>> function easily in COBOL and put it in the same library as the other
>> intrinsic functions that ARE available with VSE. Try having a chat to
>> your
>> friendly neighbourhood systems programmer... if the guy is good he might
>> be
>> very happy to to indulge you. I'd be surprised if IBM don't allow
>> maintenance of these libraries. (You're not changing any existing
>> functionality, just extending it....now, where have we heard that
>> before...?
>
> I've seen no indication that this is possible, and even if it were I doubt
> my system programmers would touch it with a 100 foot pole. Though if it
> were possible I'd try to give it a shot. But it's very unlikely.
>
>>
>> Here's another idea :-) Why not write your function/module/whatever then
>> replace one of the unused intrinsics with it (say COS...) if there
>> really is
>> no way to add to the compiler's function library... (no, Frank, I was
>> joking...:-))
>
> No idea how to do this either, but I'm sure something so unsupported would
> never be allowed in production.
>
> Frank
>
I'm sure you're right...

These days with "best practices" and SOPs and standards and dire warnings
from vendors if you mess with their products, there isn't much fun any
more...:-)

I remember a time when we were constrained by none of this and just did what
was necessary... :-)

When I look back over some of the things I've been required to do in my
career, it makes me smile. Here are some examples which I couldn't see
being even entertained today....

1. Patch a COBOL compiler so it can read magnetic tape or disk input instead
of just punch cards.
2. Write a facility to save object programs from a fixed disk, where the
compiler put them, into a library on tape, that could be reloaded and
reused, so that compilation wasn't necessary every time you needed to run an
application.
3. Find which pass of the COBOL compiler deals with generation for IF
statements and fix it so that else branch code is only generated when it
actually needs to be, instead of "always"...
4. Write a common interface that traps DL/1 calls and re-interprets them to
SQL so that all our DL/1 programs can be switched to DB2.
5. Write a common interface that traps TASKMASTER calls and converts them
to IMS/DC.
6. Write an application that allows users to specify their own search
criteria and generate a program to do it. (This was before SQL was
invented).
7. Devise a common data access layer that would allow COBOL to run across
different platforms (IBM and ICL... but theoretically ANY) so that the same
processing can occur against completely different data management systems.
8. Write something that will allow Fujitsu mainframe applications to run on
a PC, with the same look and feel. (This was a tragedy for me... I did it,
got it working, demonstrated it to Fujitsu (Australia) and had a handshake
on a deal that would have had me retired at 42 years of age (multimillion
dollar deal). The day before the contract was to be signed the whole deal
with their customer collapsed and they couldn't proceed. :-). I shrugged,
paid my associates and walked away, but my wife was devasted... she was
already buying shoes :-)

There are more, but you catch my drift... :-)

Adding a new intrinsic function to an IBM COBOL compiler really isn't such a
big deal... :-)

Pete.
--
"I used to write COBOL...now I can do anything."





First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: S0C4 x'4' abend while reading VSAM KSDS file
Next: COBOL: Don`t Call It a Comeback