Re: The POSiX Animal On An MPE Box - Hewlett Packard

This is a discussion on Re: The POSiX Animal On An MPE Box - Hewlett Packard ; My problem is only rearing its ugly head with bytestream files. The flimit for the FOPEN is defined as a 32 bit signed integer (accordingto the Intrinsics manual) so I defined the field as PIC S9(09) COMP. Will my call ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Re: The POSiX Animal On An MPE Box

  1. Re: The POSiX Animal On An MPE Box

    My problem is only rearing its ugly head with bytestream files.

    The flimit for the FOPEN is defined as a 32 bit signed integer (accordingto
    the Intrinsics manual) so I defined the field as PIC S9(09) COMP.

    Will my call to FOPEN be thrown off into la-la land if I define the flimit
    field as PIC S9(10) COMP ?

    The flimit on bytestream files is actually 10 digits long not nine, that is
    why I was losing the leftmost value (2) on my build statement.

    I am seriously tempted to stop users from processing bytestream files which
    would be the easiest solution to this problem.

    My other problem, and even bigger problem with bytestream files is in
    writing records to the file.

    It is defined as a one byte rec size file but FLABELINFO says the rec size
    = 8192 bytes (item 30, a U32 field)

    I need to be able to build a temp file as an 8192 byte rec size file so that
    I can FWRITE records to the file which may be an 80 byte record, 256 byte
    record, "n" byte record, not one byte which will cause a serious truncation
    of data. However, if I build the temp "bytestream" file with an 8192 byte
    rec len
    then it is not truly a bytestream file.

    Any other suggestions ?

    As I said, I am seriously tempted to stop users from processing bytestream
    files which would be the easiest solution to this problem.


    Brian.


    On Sun, 17 Aug 2008 19:50:02 -0400, Gilles Schipper wrote:

    >At 07:14 PM 08-08-17, Brian Donaldson wrote:
    >
    >>Brian retorts:
    >>
    >>1) Unfortunately, the flimit parm on the FOPEN uses a PIC S9(09) comp field
    >>and that is what is dropping off the 2. Any suggestions on how to get around
    >>this little snafu?

    >
    >Yes.
    >
    >One of the problems with COBOL is how it handles binary data.
    >
    >For example, an item defined as PIC S9(04) COMP occupies 2 bytes of
    >real-estate and can have a maximum value of 9999 - even though the 16
    >bits represented by the 2-byte field can actually contain a value as
    >high as 2 to the power of 16, less 1, which equals 65,535.
    >
    >So, if you really want to account for this fact, you need to move the
    >field non-numerically to a larger COBOL field, examine its true
    >contents (allowing its true maximum value to be revealed), perform
    >some operation on it (if necessary) then move it back (again
    >non-numerically) back to its originally-sized field if required to be
    >again utilized in its smaller form.
    >
    >To illustrate:
    >
    >WORKING-STORAGE SECTION.
    >
    > 01 full-size-number1.
    > 05 filler PIC X(02).
    > 05 number1 PIC S9(04) COMP.
    > 01 full-size-number2.
    > 05 number2 PIC S9(05) COMP.
    >*please note that full-size-number2 is 4-bytes in length.
    > 01 display-number PIC ZZ,ZZ9.
    >
    >PROCEDURE DIVISION.
    >
    >MOVE full-size-number1 TO full-size-number2.
    >MOVE number2 TO display-number.
    >DISPLAY "The actual value contained in number1 is actually:", display-number.
    >
    >It's left an exercise to the reader to extrapolate this technique to
    >larger size COMP fields, such as PIC S9(09).
    >
    >
    >
    >-------------------------------------------------------------------------------------------------
    >Gilles Schipper
    >GSA Inc.
    >HP System Administration Specialists
    >300 John Street, Box 87651 Thornhill, ON Canada L3T 7R4
    >Voice: 905.889.3000 Fax: 905.889.3001
    >email: gilles@gsainc.com web: http://www.gsainc.com
    >-------------------------------------------------------------------------------------------------
    >
    >* To join/leave the list, search archives, change list settings, *
    >* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *


    * To join/leave the list, search archives, change list settings, *
    * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *


  2. Re: The POSiX Animal On An MPE Box

    The FOPEN requires a double-word FLIMIT parameter as part of the
    calling sequence.

    Thus, you CANNOT pass it an 4-word parameter - as would be the case
    if defined as S9(10).

    So, you need to perform the non-numeric MOVE trick to a different
    field as cited in my earlier example.

    So, modifying my earlier example, this time for a PIC S9(09) field,
    instead of a PIC S9(04) field:

    WORKING-STORAGE SECTION.

    01 full-size-number1.
    05 FILLER PIC X(04).
    05 number1 PIC S9(09) COMP.
    01 full-size-number2.
    05 number2 PIC S9(10) COMP.
    01 full-size-numberx REDEFINES full-size-number2.
    05 first-four-bytes PIC X(04).
    05 last-four-bytes PIC X(04).

    PROCEDURE DIVISION.

    MOVE 1,234,567,890 TO number2.
    MOVE last-four-bytes TO full-size-number1.
    CALL INTRINSIC FOPEN USING ..... number1 .....

    The only thing that matters is that the intrinsic is passed the
    proper length parameter.

    To overcome the COBOL problem that limits the number of digits
    represented by a COMP field to a constrained shorter length, you must
    "fake it out".

    Hopefully the above example illustrates this.



    At 10:36 PM 08-08-17, Brian Donaldson wrote:
    >My problem is only rearing its ugly head with bytestream files.
    >
    >The flimit for the FOPEN is defined as a 32 bit signed integer (according to
    >the Intrinsics manual) so I defined the field as PIC S9(09) COMP.
    >
    >Will my call to FOPEN be thrown off into la-la land if I define the flimit
    >field as PIC S9(10) COMP ?
    >
    >The flimit on bytestream files is actually 10 digits long not nine, that is
    >why I was losing the leftmost value (2) on my build statement.
    >
    >I am seriously tempted to stop users from processing bytestream files which
    >would be the easiest solution to this problem.
    >


    Gilles Schipper
    GSA Inc.
    HP System Administration Specialists
    300 John Street, Box 87651 Thornhill, ON Canada L3T 7R4
    Voice: 905.889.3000 Fax: 905.889.3001
    email: gilles@gsainc.com web: http://www.gsainc.com
    -------------------------------------------------------------------------------------------------

    * To join/leave the list, search archives, change list settings, *
    * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *


  3. Re: The POSiX Animal On An MPE Box

    Following is an actual example that demonstrates that the COBOL PIC
    S9(04) COMP limit is not exactly as it appears to be:


    :cob85xlg cobols


    PAGE 0001 COBOL II/iX HP31500A.04.19 [85] Copyright Hewlett-Packard CO. 1987


    00001 COBCNTL 000100* The following are defaults for
    Compatibility mode compi

    ler.
    00002 COBCNTL 000200*CONTROL
    LIST,SOURCE,NOCODE,NOCROSSREF,ERRORS=100,NOVERBS,

    WARN
    00003 COBCNTL 000300*CONTROL
    LINES=60,NOMAP,MIXED,QUOTE=",NOSTDWARN,SYNC16,IND

    EX16
    00004 COBCNTL 000400*
    00005 COBCNTL 000500* The following are defaults for Native compiler.
    00006 COBCNTL 000600*
    00007 COBCNTL 000700*CONTROL
    LIST,SOURCE,NOCODE,NOCROSSREF,ERRORS=100,NOVERBS,

    WARN
    00008 COBCNTL 000800*CONTROL
    LINES=60,NOMAP,MIXED,QUOTE=",NOSTDWARN,SYNC32,IND

    EX32
    00009 COBCNTL 000900*CONTROL NOVALIDATE,OPTIMIZE=0
    00010 COBCNTL 001000*
    00011 COBCNTL 001100* For any other options, redirect
    COBCNTL.PUB.SYS by usi

    ng
    00012 COBCNTL 001200* a file equation.
    00013 COBCNTL 001300*
    00014 001000$CONTROL USLINIT
    00015 001100 IDENTIFICATION DIVISION.
    00016 001200 PROGRAM-ID. TEST.
    00017 001700 ENVIRONMENT DIVISION.
    00018 001800 CONFIGURATION SECTION.
    00019 001900 SOURCE-COMPUTER. HP3000.
    00020 002000 OBJECT-COMPUTER. HP3000.
    00021 002100 SPECIAL-NAMES.
    00022 002200 CONDITION-CODE IS cond-code
    00023 002300 TOP IS new-page.
    00024 002400 INPUT-OUTPUT SECTION.
    00025 002500 DATA DIVISION.
    00026 002600 WORKING-STORAGE SECTION.
    00027 002700 01 group-item1.
    00028 002800 05 FILLER PIC X(02).
    00029 002900 05 number1 PIC S9(04) COMP.
    00030 003000 01 group-item2.
    00031 003100 05 number2 PIC S9(05) COMP.
    00032 003200 01 display-item PIC ZZ,ZZ9.
    00033 003300
    00034 007500 PROCEDURE DIVISION.
    00035 007600 a-control.
    00036 007700 MOVE 32768 TO number2.
    00037 007800 MOVE group-item2 TO group-item1.
    00038 007900 MOVE number1 TO display-item.
    00039 008000 DISPLAY "number1 is: ", display-item.
    00040 008100 MOVE number2 TO display-item.
    00041 008200 DISPLAY "number2 is: ", display-item.
    00042 008300 GOBACK.


    0 ERROR(s), 0 QUESTIONABLE, 0 WARNING(s)

    DATA AREA IS 40 BYTES.
    CPU TIME = 0:00:00. WALL TIME = 0:00:00.

    END OF PROGRAM
    END OF COMPILE
    HP Link Editor/iX (HP30315A.06.21) Copyright Hewlett-Packard Co 1986

    LinkEd> link

    END OF LINK

    number1 is: 32,768
    number2 is: 32,768

    END OF PROGRAM
    :

    Notice that even though number1 is defined as PIC S9(04) COMP, it can
    actually contain a value as high as will fit in 15 bits. (If it were
    unsigned, it could contain a number twice as large since its value
    could be as large as contained in 16 bits - which would be 65536.


    -------------------------------------------------------------------------------------------------
    Gilles Schipper
    GSA Inc.
    HP System Administration Specialists
    300 John Street, Box 87651 Thornhill, ON Canada L3T 7R4
    Voice: 905.889.3000 Fax: 905.889.3001
    email: gilles@gsainc.com web: http://www.gsainc.com
    -------------------------------------------------------------------------------------------------


    * To join/leave the list, search archives, change list settings, *
    * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *


  4. Re: The POSiX Animal On An MPE Box

    Hi Brian,

    Part of the problem that you are seeing has to do with the way you are accessing the byte stream record files. The introduction of byte stream files on MPE/iX created an interesting challenge. The behavior of byte stream files is different than the behavior that "normal" MPE applications would expect when dealing with files. The MPE file system is record based - an application could issue an FREAD request of 100 bytes, but be assured that it would be returned only a record's worth of data (assuming the record size was less than 101 bytes, in this example.) If you requested a read of 100 bytes against a byte stream file, you'd get 100 bytes which may include one or many whole or partial records.

    POSIX applications expect this behavior, but existing MPE applications would not be able to correctly handle byte stream files without being rewritten.. The same thing is true for POSIX applications accessing the classic MPE file and record types. Padded records and structured files would cause POSIXapplications all sorts of difficulties.

    The solution that we chose was to introduce the concept of a user selectable data format view. At open time, you specify whether you want to treat thefile data from a record based perspective, or a byte stream perspective. FOPEN only allows record based, HPFOPEN allows you to choose via option 77. This ability to view the same data differently allows MPE/iX API applications to work on byte stream files without change, and also allows POSIX-basedAPI applications to work on fixed and variable length record files, also without change.

    The magic of providing multiple views of the same data is accomplished through emulators that the file system provides. Although very useful, there are always limits to the transparency of an emulator. When representing a byte stream file to an application as a "record based file", the variable record format was chosen, since it most closely matched the semantics of byte stream files. In byte stream files there are no blocks or maximum record sizes, so values had to be arbitrarily chosen. In this case, 8KB (8092) bytes was chosen to be reported - this was the maximum record size that the emulator would return.

    So, if you open a byte stream file and request a standard record based viewof the file (which is the default), FFILEINFO will report back to you thatthe file is variable record, with a record size of 8,192 bytes. This doesn't represent the actual physical layout of the file, but it does represent the behavior that was requested at open time, and how the file system will treat data that is read or written to the file. It is the data that MPE based applications need in order to operate correctly on the byte stream files..

    FLABELINFO is a different animal. FLABELINFO retrieves file information on a file by its name - there is no open file handle/number associated with the information request, and no indication of how you want to operate on or view the data in the file. Because of this, FLABELINFO always returns information about the physical characteristics of the file. For byte stream record files the record type will always be 9 (byte stream record), and the record size will always be 1 byte.

    In order to correctly build your file copies, you'll need to call FLABELINFO to get the physical file characteristics. The values that you are using are coming from FFILEINFO, after you've opened the file for record based access. After you've built the file with the correct physical characteristics,you can continue to use the record based data view to read and write data to it.

    Sorry about the long-windedness, but it seemed to me that some understanding of the nature of the data view associated with byte stream files was necessary to understand where the variable record, 8,192 byte values were coming from.

    Take Care,
    Craig

    ....
    > My other problem, and even bigger problem with bytestream
    > files is in writing records to the file.
    >
    > It is defined as a one byte rec size file but FLABELINFO says
    > the rec size = 8192 bytes (item 30, a U32 field)
    >
    > I need to be able to build a temp file as an 8192 byte rec
    > size file so that I can FWRITE records to the file which may
    > be an 80 byte record, 256 byte record, "n" byte record, not
    > one byte which will cause a serious truncation of data.
    > However, if I build the temp "bytestream" file with an 8192
    > byte rec len then it is not truly a bytestream file.
    >
    > Any other suggestions ?
    >
    > As I said, I am seriously tempted to stop users from
    > processing bytestream files which would be the easiest
    > solution to this problem.
    >
    >
    > Brian.

    ....

    * To join/leave the list, search archives, change list settings, *
    * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *


+ Reply to Thread