How would you do this?
in [Cobol]
|
From: William M. Klein on 10 Mar 2007 14:13 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 Klein wmklein <at> ix.netcom.com
From: Rick Smith on 10 Mar 2007 21:12 "William M. Klein" <wmklein(a)nospam.netcom.com> wrote in message news:rrDIh.242220$k82.140284(a)fe07.news.easynews.com... > 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. There are a lot of "reserved" bits in the four full-words. While some of these may become assigned, it seems unlikely that any would be moved. As new bits become assigned, a routine that processes all bits, such as a "division loop" would, I believe, be more sensitive to maintenance than one that extracts the bit fields directly. Also one need not extract more than is desired. Extracting these bit fields directly seems a rather straight-forward process with intrinsic functions. The exponents below are 31 minus the low-order bit number of the field. ----- compute c-bit = function mod (function integer (member-id / (2 ** 28)) 2) compute cobol-bit = function mod (function integer (member-id / (2 ** 26)) 2) compute amode = function mod (function integer (env-info / (2 ** 17)) 4) compute product-number = function integer (gpid / (2 ** 24)) compute version = function mod (function integer (gpid / (2 ** 16)) 256) compute releasse = function mod (function integer (gpid / (2 ** 8)) 256) compute modification = function mod (gpid 256) -----
From: William M. Klein on 10 Mar 2007 23:21 Richard, Are you assuming that "Moded fields" are USAGE BINARY-CHAR - or a "BINARY" (with non-ANSI "notrunc" behavior). Otherwise, I don't know how you are processing them. This is part of my problem in "solving" this problem. Standard COBOL (pre- USAGE BINARY-CHAR) has no way to define a numeric field as "binary" without truncation. -- Bill Klein wmklein <at> ix.netcom.com "Rick Smith" <ricksmith(a)mfi.net> wrote in message news:12v6pek1atd1a64(a)corp.supernews.com... > > "William M. Klein" <wmklein(a)nospam.netcom.com> wrote in message > news:rrDIh.242220$k82.140284(a)fe07.news.easynews.com... >> 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. > > There are a lot of "reserved" bits in the four full-words. > While some of these may become assigned, it seems > unlikely that any would be moved. As new bits become > assigned, a routine that processes all bits, such as a > "division loop" would, I believe, be more sensitive to > maintenance than one that extracts the bit fields directly. > Also one need not extract more than is desired. > > Extracting these bit fields directly seems a rather > straight-forward process with intrinsic functions. The > exponents below are 31 minus the low-order bit number > of the field. > > ----- > compute c-bit = function mod > (function integer (member-id / (2 ** 28)) 2) > compute cobol-bit = function mod > (function integer (member-id / (2 ** 26)) 2) > compute amode = function mod > (function integer (env-info / (2 ** 17)) 4) > compute product-number = function integer > (gpid / (2 ** 24)) > compute version = function mod > (function integer (gpid / (2 ** 16)) 256) > compute releasse = function mod > (function integer (gpid / (2 ** 8)) 256) > compute modification = function mod > (gpid 256) > ----- > > >
From: Louis Krupp on 10 Mar 2007 23:25 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") I'd consider writing a C routine that would explode the bitmaps into tables of 32 integers (PIC 9 COMP or PIC 9 DISPLAY or whatever works). You'd have to make sure you knew how the table would be laid out in memory, so you might consider sacrificing memory and speed for portability. The 32-bit word with four 8-bit fields could be split into four PIC 99 fields. The good thing is that the C code wouldn't have to know what any of the bits meant, and you wouldn't have to do anything fancy in COBOL to get the information you need. Louis
From: Louis Krupp on 11 Mar 2007 00:37 Louis Krupp wrote: > 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") > > I'd consider writing a C routine that would explode the bitmaps into > tables of 32 integers (PIC 9 COMP or PIC 9 DISPLAY or whatever works). > You'd have to make sure you knew how the table would be laid out in > memory, so you might consider sacrificing memory and speed for > portability. The 32-bit word with four 8-bit fields could be split into > four PIC 99 fields. Oops. Make that PIC 9(3). Louis
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: Cobol convert program Job Request Next: Conversion of data & associated logic from ISAM to RDB |