Prev: Cobol convert program Job Request
Next: Conversion of data & associated logic from ISAM to RDB
From: Rick Smith on 12 Mar 2007 15:05

"HeyBub" <heybubNOSPAM(a)gmail.com> wrote in message
news:12vam7smnj5dmd8(a)news.supernews.com...
> William M. Klein wrote:
> > Now, my question is how various "experienced" COBOL programmers would
> > handle such information (either in an IBM mainframe environment OR in
> > other COBOL environments for those who see this note and don't work
> > in IBM mainframe environments - but do get "bit maps")
>
> By reducing the problem to one that's already been solved?

I thought about recommending ETKPAK, as well;
but rejected it as "overkill" and my feeling that it
did not solve the problem of obtaining the values
of multi-bit fields.

> From the ETK collection of nifty subroutines:
[snip]
> 02 BITPK-NUMBER PIC 9(10).

Be aware that this field is has usage COMP in the
linkage section of the called program.



From: HeyBub on 12 Mar 2007 15:08
Rick Smith wrote:
> "HeyBub" <heybubNOSPAM(a)gmail.com> wrote in message
> news:12vam7smnj5dmd8(a)news.supernews.com...
>> William M. Klein wrote:
>>> Now, my question is how various "experienced" COBOL programmers
>>> would handle such information (either in an IBM mainframe
>>> environment OR in other COBOL environments for those who see this
>>> note and don't work in IBM mainframe environments - but do get "bit
>>> maps")
>>
>> By reducing the problem to one that's already been solved?
>
> I thought about recommending ETKPAK, as well;
> but rejected it as "overkill" and my feeling that it
> did not solve the problem of obtaining the values
> of multi-bit fields.
>

Well not directly, it doesn't. It takes a 32-bit value and maps it to 32
one-byte fields which can be individually tested. The rest is left as an
exercise for the reader.


From: Rick Smith on 12 Mar 2007 16:38

"William M. Klein" <wmklein(a)nospam.netcom.com> wrote in message
news:6dRIh.197862$Wn.83634(a)fe06.news.easynews.com...
> You may be right (but I am still not certain) for IBM mainframes.
According to:
>
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg32/2.4.54
[I used <
http://publib.boulder.ibm.com/infocenter/pdthelp/v1r1/index.jsp?topic=/com.i
bm.entcobol4.doc/up4060.htm >.]
>
> "TRUNC(STD) applies only to USAGE BINARY receiving fields in MOVE
statements and
> arithmetic expressions."

"receiving fields"; not "sending fields"!

> but it then goes on to say,
> "When TRUNC(STD) is in effect, the final result of an arithmetic
expression,
> ..., is truncated"

And continues with "to the number of digits in the
PICTURE clause of the BINARY receiving field."

> So I am not certain where in your compute statement the truncation would
occur
> (if at all), i.e. for the "arithmetic expression" (evaluation) or in the
FINAL
> move to the receiving field.

Let me emphasize "receiving field".

> I don't (easily) have an Enterprise COBOL system
> to test with, so I can't tell for sure. (I just "in general" HATE to rely
on
> any stage of USAGE BINARY items where the data is larger than the
PICTURE).

And IBM recognizes your concern:

"Recommendations: TRUNC(BIN) is the recommended
option for programs that use binary values set by other
products. Other products, such as IMS, DB2, C/C++,
FORTRAN, and PL/I, might place values in COBOL
binary data items that do not conform to the PICTURE
clause of the data items."

[snip]
> "Rick Smith" <ricksmith(a)mfi.net> wrote in message
> news:12v7j5rd1ec59cd(a)corp.supernews.com...
[snip]
> > PIC 9(9) BINARY
> >
> > The call to CEE3INF, as I understand it, will return the
> > values untruncated. Since truncation occurs when the
> > COBOL program stores the result of a calculation, I
> > don't see truncation, from the COMPUTE statements,
> > as a problem.
> >
> > The worrisome case appears to be getting bit 0 of a field,
> > such as, the CICS bit from sys/subsys; since this would
> > involve division by +2147483648 (2 ** 31).
> >
> > compute cics-bit = function mod
> > (function integer (sys-subsys / (2 ** 31)) 2)
> >
> > This statement correctly returns either +1 or +0 with
> > ANSI truncation (the default) in effect, on Micro Focus
> > COBOL 3.2.24.
> >
> > -----
> > $set ibmcomp vsc2 arithmetic"vsc2"
> > identification division.
> > program-id. test3inf.
> > working-storage section.
> > 01 sys-subsys pic 9(9) binary value 0.
> > 01 cics-bit pic s9(4) binary value +0.
> > procedure division.
> > begin.
> > move x"80000000" to sys-subsys (1:4)
> > compute cics-bit = function mod
> > (function integer (sys-subsys / (2 ** 31)) 2)
> > if cics-bit = +1
> > display "CICS bit is on"
> > end-if
> > goback.
> > -----
[snip]



From: Pete Dashwood on 12 Mar 2007 19:28

"CG" <Carl.Gehr.ButNoSPAMStuff(a)MCGCG.Com> wrote in message
news:55953$45f4e0a0$4275fbdb$18078(a)FUSE.NET...
> Pete Dashwood wrote:
>> "CG" <Carl.Gehr.ButNoSPAMStuff(a)MCGCG.Com> wrote in message
>> news:9fdc5$45f4ba41$4275fbdb$21645(a)FUSE.NET...
>>> William M. Klein wrote:
>>>> to: comp.lang.cobol *and* IBM-MAIN
>>>>
>>>> IBM has (relatively) recently created an LE callable service, CEE3INF,
>>>> that returns a "32-bit map" with information about what environment a
>>>> program is running in. See:
>>>>
>>>>
>>>> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CEEA3170/2.2.5.9
>>>>
>>>> Now, my question is how various "experienced" COBOL programmers would
>>>> handle such information (either in an IBM mainframe environment OR in
>>>> other COBOL environments for those who see this note and don't work in
>>>> IBM mainframe environments - but do get "bit maps")
>>>>
>>>> 1) Call a non-COBOL program to decode this map (e.g.. Assembler, C,
>>>> PL/I or any other language that can easily handle "bits")
>>>>
>>>> 2) Do a "division" loop to figure out which bits are turned on?
>>>>
>>>> 3) Use 88-levels with hex literals to check for which bits were turned
>>>> on?
>>>>
>>>> 4) Use the LE (or comparable) "bit manipulation" routines?
>>>>
>>>> 5) Not use CEE3INF from COBOL?
>>>>
>>>> 6) Other?
>>>>
>>>> ***
>>>>
>>>> Although I wouldn't LIKE it, I can imagine doing this in any of these
>>>> ways. Obviously, when/if a COBOL compiler supports the '02 Standard
>>>> Bit/Boolean features, this becomes "trivial". However, as few (if any)
>>>> compilers do this yet, I was wondering how programmers would handle
>>>> this requirement.
>>>>
>>> Bill,
>>> Since you are already using LE Callable Services, why not use:
>>>
>>>> CEESITST: Bit test
>>>> * CEESITST selectively tests a bit in its parm1 input to determine if
>>>> the bit is on.
>>>>
>>>> Syntax
>>>> CEESITST (parm1 ,parm2 ,fc ,result )
>>>> Where:
>>>> parm1 (input)
>>>> The first input to the Bit Test routine. The input
>>>> can be any 32-bit integer.
>>>> parm2 (input)
>>>> The second input to the Bit Test routine. The input
>>>> is a 32-bit integer in the range 0 =< parm2 =< 31.
>>>> fc (output)
>>>> A 12-byte feedback code, optional in some languages,
>>>> that indicates the result of this service.
>>>>
>>>> The following symbolic conditions can result from this service:
>>>> result (output)
>>>> The result of the Bit Test routine. The output is a
>>>> 32-bit integer with value:
>>>> 1, if bit number parm2 in parm1 is 1
>>>> 0, if bit number parm2 in parm1 is 0
>>>> Bits are counted from the right.
>>> Ref: Language Environment Programming Reference
>>> Chapter 5: Bit manipulation routines
>>> SA22-7562-08 [z/OS V1.8]
>>> Carl
>>
>> That looks fine Carl and was the approach I adopted about 9 years ago
>> when I first had this problem. (Use callable bit manipulation routines
>> provided in the environment.)
>>
>> I have a few reservations (although I agree it is a perfectly valid
>> solution in the stated environment):
>>
>> 1. If you are looking for a general solution (for cases where you AREN'T
>> calling CEE3INF for example... you just need to "interpret" a bit
>> string...) this becomes less attractive. Calling either of these
>> routines ties you to a specific environment.
>>
>> 2. Rick's solution will work in almost any environment and is very few
>> lines of code without having to worry about CALL and parameters. It is
>> solid COBOL and should work in any COBOL environment where they support
>> intrinsic functions.
>>
>> 3. If you are going to call anything, it would be better to call a
>> non-environment specific module or object. Java presents itself here as a
>> prime candidate.
>>
>> 4. I was surprised the routine above returns a binary number that is 1 or
>> 0; in the IBM environment I would have expected a byte, which is much
>> more amenable to CLC and CLI, instructions without requiring any
>> conversion. I suspect that collating sequences other than just plain
>> EBCDIC are being considered here...
>>
>> Left to my own devices, I would've opted for the Java/COBOL mix and made
>> it an OO Class, invokable from COBOL. I like Rick's solution much better.
>>
>> Pete.
>>
>> PS I don't hink it is fair for this thread to refer to this process as
>> "bit mapping". This term has a specific meaning and connotation in other
>> environments. What is happening here is interpretation (deriving meaning
>> from), or analysis of, a bit string.
>
> First, an obvious point: The reason this approach is applicable is
> because it means that the programmer/user does not have to do anything
> special other than use the service provided... It's part of the system.

So is Java ... :-)

>
> As you would probably expect, please consider that Bill's question was
> very specific to his objection to the implementation of CEE3INF. This
> service is not only explicit to LE, but the '3' in the name makes it even
> more specific to the "S/390" [read mainframe, OS/390, MVS, z/OS, et al]
> environment. Therefore, there is no situation where someone using CEE3INF
> would not also have clear access to the Bit Manipulation services that I
> suggested. [There are, BTW, a set of four services for setting, clearing,
> shifting and testing bits.]

No, I understand that, my reservation was about the case where the bit
string interpretation might be required for cases OTHER than the one Bill
raised.

I wasn't aware he was "objecting" ... seems to me he simply asked what
people would do.

>
> I don't find the binary returned value objectionable because it is highly
> unlikely that you would ever actually translate the value to anything,
> much less a character. You test it with a relatively fast compare and get
> on with the logic.

Sure. It wasn't an objection; just something I noted in passing.
>
> Certainly, if you want to broaden the subject to include all situations of
> bit mangling, then native language [IMHO] is the only way to go.

Certainaly that is an arguable option.

> And, if you are in control of the application design and know you are
> lacking such language, change the design to match the features you do
> have.

Sounds a bit like the tail wagging the dog... :-) Nevertheless, I agree it
is a bit pointless designing stuff that cannot be implemented with the
materials and tools at hand.
>
> Finally, your objection to 'bit mapping' is noted, but a FIND in the
> message text returned your use of the word 'mapping' as the only instance.

Hmmm... I checked each message I have posted to this thread and I can't find
that. Are you sure it wasn't quoted within a message from me? It doesn't
really matter anyway; again it was an observation in passing.

Pete.


From: William M. Klein on 12 Mar 2007 21:20
Just a point of clarification (and explanation)

Carl is aware of my OBJECTION to the way that CEE3INF returns its information
(from other ways that we communicate).

As far as the comp.lang.cobol thread goes, I really was interested in exactly
HOW experienced COBOL programmers (both in and out of an IBM LE environment)
would handle the requirement to "decode" the bits within a 1 byte (or larger)
string of bits. I was also interested in how this would be solved in situations
where one is interested in only the single value of a single bit vs the case
where one might want to see the entire "layout" of the string of bits.

I have been interested in responses that were related specially to the LE
environment (z/OS *or* VSE). However, I have also been interested in responses
that represent other (possibly more portable) solutions to the general problem.

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


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Cobol convert program Job Request
Next: Conversion of data & associated logic from ISAM to RDB