LBR function result codes still not available - VMS

This is a discussion on LBR function result codes still not available - VMS ; Back in 1991 someone posted a complaint about the LBR$_* function return codes not being present in the language specific include files. In 1999 after another complaint, Hoff indicated he had filed a problem report with OpenVMS engineering to get ...

+ Reply to Thread
Results 1 to 19 of 19

Thread: LBR function result codes still not available

  1. LBR function result codes still not available

    Back in 1991 someone posted a complaint about the LBR$_* function
    return codes not being present in the language specific include
    files. In 1999 after another complaint, Hoff indicated he had filed a
    problem report with OpenVMS engineering to get it fixed.

    Today I had to write a program to play with libraries. Unfortunately
    it looks like those return codes are _still_ not available in the
    language specific include files; I checked Macro, C, and BASIC on my
    V7.3-2 system, then to be certain did the same on a V8.3 (Alpha) box.
    Same results; the codes are not there.

    I guess using the LBR$ functions in a user written program must be a
    pretty rare event. Whats the best way to try and get this back on
    someone's burner? I don't have real VMS support any more (just DSPP
    access) and if time allows I'll try to get something done tomorrow.
    Any other options? If Hoff's internal report garnered no results I'm
    not hopeful about anything I do (and it won't help the current
    situation in any case).

    Comments about this being proof VMS is dead and has been since 1991
    please pipe to NLA0:. There's enough noise in this group already.

    Thanks

    Rich

  2. Re: LBR function result codes still not available

    On Thu, 29 May 2008 15:54:00 -0700, Rich Jordan wrote:

    > Back in 1991 someone posted a complaint about the LBR$_* function
    > return codes not being present in the language specific include
    > files. In 1999 after another complaint, Hoff indicated he had filed a
    > problem report with OpenVMS engineering to get it fixed.
    >
    > Today I had to write a program to play with libraries. Unfortunately
    > it looks like those return codes are _still_ not available in the
    > language specific include files; I checked Macro, C, and BASIC on my
    > V7.3-2 system, then to be certain did the same on a V8.3 (Alpha) box.
    > Same results; the codes are not there.
    >
    > I guess using the LBR$ functions in a user written program must be a
    > pretty rare event. Whats the best way to try and get this back on
    > someone's burner? I don't have real VMS support any more (just DSPP
    > access) and if time allows I'll try to get something done tomorrow.
    > Any other options? If Hoff's internal report garnered no results I'm
    > not hopeful about anything I do (and it won't help the current
    > situation in any case).
    >
    > Comments about this being proof VMS is dead and has been since 1991
    > please pipe to NLA0:. There's enough noise in this group already.


    In which module do you expect to find those?

    FREJA> pipe lib/list sys$library:PLI$STARLET.TLB|grep lbr
    $LBRCTLTBL
    $LBRDEF
    LBR$CLOSE
    LBR$DELETE_DATA
    LBR$DELETE_KEY
    LBR$FIND
    LBR$FLUSH
    LBR$GET_HEADER
    LBR$GET_HELP
    LBR$GET_HISTORY
    LBR$GET_INDEX
    LBR$GET_RECORD
    LBR$INI_CONTROL
    LBR$INSERT_KEY
    LBR$LOOKUP_KEY
    LBR$LOOKUP_TYPE
    LBR$MAP_MODULE
    LBR$OPEN
    LBR$OUTPUT_HELP
    LBR$PUT_END
    LBR$PUT_HISTORY
    LBR$PUT_RECORD
    LBR$REPLACE_KEY
    LBR$RET_RMSSTV
    LBR$SEARCH
    LBR$SET_INDEX
    LBR$SET_LOCATE
    LBR$SET_MODULE
    LBR$SET_MOVE
    LBR$UNMAP_MODULE
    LBRUSR

    >
    > Thanks
    >
    > Rich




    --
    PL/I for OpenVMS
    www.kednos.com

  3. Re: LBR function result codes still not available

    Tom Linden wrote:
    > On Thu, 29 May 2008 15:54:00 -0700, Rich Jordan wrote:
    >> Back in 1991 someone posted a complaint about the LBR$_* function
    >> return codes not being present in the language specific include
    >> files. In 1999 after another complaint, Hoff indicated he had filed a
    >> problem report with OpenVMS engineering to get it fixed.
    >>
    >> Today I had to write a program to play with libraries. Unfortunately
    >> it looks like those return codes are _still_ not available in the
    >> language specific include files; I checked Macro, C, and BASIC on my
    >> V7.3-2 system, then to be certain did the same on a V8.3 (Alpha) box.
    >> Same results; the codes are not there.


    > In which module do you expect to find those?
    >
    > FREJA> pipe lib/list sys$library:PLI$STARLET.TLB|grep lbr
    > $LBRCTLTBL
    > $LBRDEF
    > LBR$CLOSE
    > LBR$DELETE_DATA


    LBR$* function <> LBR$_* return code

    I would say that lbrdef would make sense.

    Arne

  4. Re: LBR function result codes still not available

    lbrdef contains structures and constants needed to call the LBR$
    routines. Not the condition values returned.

  5. Re: LBR function result codes still not available

    On May 30, 4:18 am, IanMiller wrote:
    > lbrdef contains structures and constants needed to call the LBR$
    > routines. Not the condition values returned.


    I haven't checked all the language include file libraries but none of
    the ones I have checked include the return codes; this is the same
    situation reported in '91 and '99.

    Rich

  6. Re: LBR function result codes still not available

    IanMiller wrote:
    > lbrdef contains structures and constants needed to call the LBR$
    > routines. Not the condition values returned.


    I did it myself, and I am sure I would have gotten help from C.O.V. on
    how to get the ana/sys stuff.

    $ type lbrshr_codes.h
    /** LIBSHR_CODES.H
    ** extracted VAX-VMS 7.2 from
    ** ANA/SYS READ SYS$LIBRARY:LBRSHR.EXE , SHOW SYMBOL/ALL
    ** and then massages with TPU, keeping only LBR$_ codes
    **/

    #define LBR$_LIBOPN 0x0026907A
    #define LBR$_LKPNOTDON 0x00269072
    #define LBR$_NOFILNAM 0x00269082
    #define LBR$_NOHISTORY 0x00268403
    #define LBR$_NOHLPLIBS 0x00269102
    #define LBR$_NOHLPTXT 0x0026908A
    #define LBR$_NOMTCHFOU 0x00268838
    #define LBR$_NORMAL 0x00268001
    #define LBR$_NOTHLPLIB 0x00269092
    #define LBR$_NOUPDHIST 0x00268808
    #define LBR$_NULIDX 0x00268810
    #define LBR$_OLDLIBRARY 0x00268019
    #define LBR$_OLDMISMCH 0x00268818
    #define LBR$_RECLNG 0x0026909A
    #define LBR$_RECTRUNC 0x00268820
    #define LBR$_REFCNTZERO 0x002690A2
    #define LBR$_RFAPASTEOF 0x002690AA
    #define LBR$_STILLKEYS 0x00268828
    #define LBR$_TOOMNYARG 0x002690F2
    #define LBR$_TOOMNYLIB 0x002690B2
    #define LBR$_TYPMISMCH 0x00268830
    #define LBR$_UPDURTRAV 0x002690BA
    #define LBR$_USRINPERR 0x002690FA
    #define LBR$_WRITEERR 0x002690D2
    #define LBR$_ALLWRNGBLK 0x00269002
    #define LBR$_BADPARAM 0x002690C2
    #define LBR$_DUPKEY 0x0026900A
    #define LBR$_EMPTYHIST 0x0026840B
    #define LBR$_ENDTOPIC 0x00268848
    #define LBR$_ERRCLOSE 0x00268840
    #define LBR$_HDRTRUNC 0x00268800
    #define LBR$_ILLCREOPT 0x0026901A
    #define LBR$_ILLCTL 0x00269012
    #define LBR$_ILLFMT 0x0026902A
    #define LBR$_ILLFUNC 0x00269032
    #define LBR$_ILLIDXNUM 0x00269022
    #define LBR$_ILLINROU 0x002690EA
    #define LBR$_ILLOP 0x0026903A
    #define LBR$_ILLOUTROU 0x002690DA
    #define LBR$_ILLOUTWID 0x002690E2
    #define LBR$_ILLTYP 0x00269042
    #define LBR$_INTRNLERR 0x002690CA
    #define LBR$_INVKEY 0x0026904A
    #define LBR$_INVNAM 0x00269052
    #define LBR$_INVRFA 0x0026905A
    #define LBR$_KEYINDEX 0x00268009
    #define LBR$_KEYINS 0x00268011
    #define LBR$_KEYNOTFND 0x00269062
    #define LBR$_LIBNOTOPN 0x0026906A
    $



  7. Re: LBR function result codes still not available

    On Fri, 30 May 2008 11:23:40 -0700, JF Mezei
    wrote:

    > IanMiller wrote:
    >> lbrdef contains structures and constants needed to call the LBR$
    >> routines. Not the condition values returned.

    >
    > I did it myself, and I am sure I would have gotten help from C.O.V. on
    > how to get the ana/sys stuff.
    >
    > $ type lbrshr_codes.h
    > /** LIBSHR_CODES.H
    > ** extracted VAX-VMS 7.2 from
    > ** ANA/SYS READ SYS$LIBRARY:LBRSHR.EXE , SHOW SYMBOL/ALL
    > ** and then massages with TPU, keeping only LBR$_ codes
    > **/
    >
    > #define LBR$_LIBOPN 0x0026907A
    > #define LBR$_LKPNOTDON 0x00269072
    > #define LBR$_NOFILNAM 0x00269082
    > #define LBR$_NOHISTORY 0x00268403
    > #define LBR$_NOHLPLIBS 0x00269102
    > #define LBR$_NOHLPTXT 0x0026908A
    > #define LBR$_NOMTCHFOU 0x00268838
    > #define LBR$_NORMAL 0x00268001
    > #define LBR$_NOTHLPLIB 0x00269092
    > #define LBR$_NOUPDHIST 0x00268808
    > #define LBR$_NULIDX 0x00268810
    > #define LBR$_OLDLIBRARY 0x00268019
    > #define LBR$_OLDMISMCH 0x00268818
    > #define LBR$_RECLNG 0x0026909A
    > #define LBR$_RECTRUNC 0x00268820
    > #define LBR$_REFCNTZERO 0x002690A2
    > #define LBR$_RFAPASTEOF 0x002690AA
    > #define LBR$_STILLKEYS 0x00268828
    > #define LBR$_TOOMNYARG 0x002690F2
    > #define LBR$_TOOMNYLIB 0x002690B2
    > #define LBR$_TYPMISMCH 0x00268830
    > #define LBR$_UPDURTRAV 0x002690BA
    > #define LBR$_USRINPERR 0x002690FA
    > #define LBR$_WRITEERR 0x002690D2
    > #define LBR$_ALLWRNGBLK 0x00269002
    > #define LBR$_BADPARAM 0x002690C2
    > #define LBR$_DUPKEY 0x0026900A
    > #define LBR$_EMPTYHIST 0x0026840B
    > #define LBR$_ENDTOPIC 0x00268848
    > #define LBR$_ERRCLOSE 0x00268840
    > #define LBR$_HDRTRUNC 0x00268800
    > #define LBR$_ILLCREOPT 0x0026901A
    > #define LBR$_ILLCTL 0x00269012
    > #define LBR$_ILLFMT 0x0026902A
    > #define LBR$_ILLFUNC 0x00269032
    > #define LBR$_ILLIDXNUM 0x00269022
    > #define LBR$_ILLINROU 0x002690EA
    > #define LBR$_ILLOP 0x0026903A
    > #define LBR$_ILLOUTROU 0x002690DA
    > #define LBR$_ILLOUTWID 0x002690E2
    > #define LBR$_ILLTYP 0x00269042
    > #define LBR$_INTRNLERR 0x002690CA
    > #define LBR$_INVKEY 0x0026904A
    > #define LBR$_INVNAM 0x00269052
    > #define LBR$_INVRFA 0x0026905A
    > #define LBR$_KEYINDEX 0x00268009
    > #define LBR$_KEYINS 0x00268011
    > #define LBR$_KEYNOTFND 0x00269062
    > #define LBR$_LIBNOTOPN 0x0026906A
    > $
    >
    >

    OK, JF your next assignment, if you want to make it really useful
    is to take the couple of minutes to put it into SDL :-)



    --
    PL/I for OpenVMS
    www.kednos.com

  8. Re: LBR function result codes still not available

    IanMiller wrote:
    > lbrdef contains structures and constants needed to call the LBR$
    > routines. Not the condition values returned.


    Correct - it don't but it should !

    Arne

  9. Re: LBR function result codes still not available

    On May 30, 8:39*pm, Arne Vajh°j wrote:
    > IanMiller wrote:
    > > lbrdef contains structures and constants needed to call the LBR$
    > > routines. Not the condition values returned.

    >
    > Correct - it don't but it should !


    Are you sure?
    Ok, I did not think this through too long, but it is not clear to me
    those definitions should ever be hardcoded.

    By having the linker resolve them, the library function providers have
    the opportunity to change the values without requiring between-version
    recompiles. Not that I expect the values will ever change, but they
    could.

    So my gutfeel is that application code should only define 'globalvalue
    int' for those return values it actually does something with. Therefor
    it must know the names and adding for example "globalvalue int LBR
    $_ILLCREOPT", while a little tedious, is the right thing to do.

    This sentiment is echoed in the C UserGuide : 3.9.4 Testing for
    Specific Return Status Values ...
    2 ... "If you are checking return status values from other
    facilities, such as the SORT utility, you must explicitly declare the
    return
    values as globalvalue int. Consider the following example:
    globalvalue int SOR$_OPENIN;"

    The only minor problem I have with globalvalue is that it is more,
    seemingly unneeded work for the linker, and it robs the compiler from
    certain optimization opportunties. Those opportunities are larger for
    16-bit returns, which are defined as literals from ssdef.

    hth,
    Hein.

  10. Re: LBR function result codes still not available

    On May 31, 10:57*am, Hein RMS van den Heuvel
    wrote:
    > On May 30, 8:39*pm, Arne Vajh°j wrote:
    >
    > > IanMiller wrote:
    > > > lbrdef contains structures and constants needed to call the LBR$
    > > > routines. Not the condition values returned.

    >
    > > Correct - it don't but it should !

    >
    > Are you sure?


    > By having the linker resolve them, the library function providers have
    > the opportunity to change the values without requiring between-version
    > recompiles


    I shoudl point out that I lied by omision.
    You'd still have to re-link which is pretty much unacceptable for
    OpenVMS folks.

    Also, the 'globalvalue' whilest documented as the solution is at the
    same time documented as being a VAXX holdover.
    It escapse me right now as how to alternatively define a global value.
    Best I can quickly think of is to define an extern and then compare
    with the address. Yuck.
    I must be overlooking somethign simple:

    #include
    extern const int LBR$_ILLCREOPT;
    main() {
    printf (" LBR$_ILLCREOPT = %%x%08x\n", &LBR$_ILLCREOPT );
    }


    btw... if you do want to go the define route, here is a perl 'one-
    liner'

    perl -e "foreach (qx(anal/imag sys\$share:lbrshr)){$x=$1 if /(\d+)\)
    $/;print qq(#define $1 $x\n) if/(LBR\$_\w+)/}" > libdef.h

    Cheers,
    Hein.

  11. Re: LBR function result codes still not available

    Hein RMS van den Heuvel wrote:
    > On May 30, 8:39 pm, Arne Vajh°j wrote:
    >> IanMiller wrote:
    >>> lbrdef contains structures and constants needed to call the LBR$
    >>> routines. Not the condition values returned.

    >> Correct - it don't but it should !

    >
    > Are you sure?
    > Ok, I did not think this through too long, but it is not clear to me
    > those definitions should ever be hardcoded.
    >
    > By having the linker resolve them, the library function providers have
    > the opportunity to change the values without requiring between-version
    > recompiles. Not that I expect the values will ever change, but they
    > could.


    1) Practically all other return codes seems to be there.

    2) If HP decided to change those values, then it would
    cause a ton of disasters.

    Arne

  12. Re: LBR function result codes still not available

    On Sat, 31 May 2008 20:01:25 -0700, Arne Vajh°j wrote:

    > Hein RMS van den Heuvel wrote:
    >> On May 30, 8:39 pm, Arne Vajh°j wrote:
    >>> IanMiller wrote:
    >>>> lbrdef contains structures and constants needed to call the LBR$
    >>>> routines. Not the condition values returned.
    >>> Correct - it don't but it should !

    >> Are you sure?
    >> Ok, I did not think this through too long, but it is not clear to me
    >> those definitions should ever be hardcoded.
    >> By having the linker resolve them, the library function providers have
    >> the opportunity to change the values without requiring between-version
    >> recompiles. Not that I expect the values will ever change, but they
    >> could.

    >
    > 1) Practically all other return codes seems to be there.
    >
    > 2) If HP decided to change those values, then it would
    > cause a ton of disasters.


    I can not conceive of a reason why the actual values would ever need to be
    changed. The whole concept of replace constants is fundamental to sound
    software practice.

    And they should ALWAYS be expressed in SDL and made available through
    starlet.

    >
    > Arne




    --
    PL/I for OpenVMS
    www.kednos.com

  13. Re: LBR function result codes still not available

    Tom Linden wrote:

    > And they should ALWAYS be expressed in SDL and made available through
    > starlet.


    I would suspect that resources have been limited ever since the Palmer
    days and they never saw any priority to finish the original work of
    building the SDL stuff for the library routines which they probably
    thought nobody used.

    Note that the routines to get the information about a library (forget
    the name) is ill defined and documentation lacks a LOT of the
    information necessary to produce the equivalent of LIBRARY/LIST/FULL.
    There is documentation on how to get the history, but no documentation
    of what the history record formats are.

    Looks to me like they abandonned the "publishing" process of the library
    routines halfway through and never came back to it. And these days,
    their focus is on supporting new HP hardware, it is very doubtful they
    will come back to stuff dating back from late 1980s.

  14. Re: LBR function result codes still not available

    Tom Linden wrote:
    > On Sat, 31 May 2008 20:01:25 -0700, Arne Vajh°j wrote:
    >
    >> Hein RMS van den Heuvel wrote:
    >>> On May 30, 8:39 pm, Arne Vajh°j wrote:
    >>>> IanMiller wrote:
    >>>>> lbrdef contains structures and constants needed to call the LBR$
    >>>>> routines. Not the condition values returned.
    >>>> Correct - it don't but it should !
    >>> Are you sure?
    >>> Ok, I did not think this through too long, but it is not clear to me
    >>> those definitions should ever be hardcoded.
    >>> By having the linker resolve them, the library function providers have
    >>> the opportunity to change the values without requiring between-version
    >>> recompiles. Not that I expect the values will ever change, but they
    >>> could.

    >>
    >> 1) Practically all other return codes seems to be there.
    >>
    >> 2) If HP decided to change those values, then it would
    >> cause a ton of disasters.

    >
    > I can not conceive of a reason why the actual values would ever need to be
    > changed.


    I agree.

    > And they should ALWAYS be expressed in SDL and made available through
    > starlet.


    Yep.

    Arne

  15. Re: LBR function result codes still not available

    Hein RMS van den Heuvel wrote:
    >[snip]
    > Also, the 'globalvalue' whilest documented as the solution is at the
    > same time documented as being a VAXX holdover.
    > It escapse me right now as how to alternatively define a global value.
    > Best I can quickly think of is to define an extern and then compare
    > with the address. Yuck.
    > I must be overlooking somethign simple:
    >
    > #include
    > extern const int LBR$_ILLCREOPT;
    > main() {
    > printf (" LBR$_ILLCREOPT = %%x%08x\n", &LBR$_ILLCREOPT );
    > }
    > [snip]


    $ type lbr.c
    #include
    #include

    #pragma extern_model save
    #pragma extern_model globalvalue
    extern const int LBR$_ILLCREOPT;
    #pragma extern_model restore

    int main (void) {

    (void)printf ("LBR$_ILLCREOPT = %%x%08x\n", LBR$_ILLCREOPT);
    return EXIT_SUCCESS;
    }
    $ cc lbr
    $ link lbr
    $ r lbr
    LBR$_ILLCREOPT = %x0026901a
    $ write sys$output f$message (%x0026901a)
    %LBR-E-ILLCREOPT, illegal create options


    Jim.
    --
    www.eight-cubed.com

  16. Re: LBR function result codes still not available

    On Jun 1, 2:35 pm, JF Mezei wrote:
    > Tom Linden wrote:
    > > And they should ALWAYS be expressed in SDL and made available through
    > > starlet.

    >
    > I would suspect that resources have been limited ever since the Palmer
    > days and they never saw any priority to finish the original work of
    > building the SDL stuff for the library routines which they probably
    > thought nobody used.
    >
    > Note that the routines to get the information about a library (forget
    > the name) is ill defined and documentation lacks a LOT of the
    > information necessary to produce the equivalent of LIBRARY/LIST/FULL.
    > There is documentation on how to get the history, but no documentation
    > of what the history record formats are.
    >
    > Looks to me like they abandonned the "publishing" process of the library
    > routines halfway through and never came back to it. And these days,
    > their focus is on supporting new HP hardware, it is very doubtful they
    > will come back to stuff dating back from late 1980s.


    The documentation specifies that the return codes are defined in
    $LBRDEF. I suppose at this point a new bug report would be more
    likely to get that reference removed from the documentation than
    getting the startlet files updates appropriately.

    I'll agree that the LBR function documentation leaves much to be
    desired. Our task has been redefined to just use the librarian from
    DCL; it took too much time trying to get the LBR functions working.
    We're losing a little of the flexibility we wanted but the main
    functionality will be just fine.

  17. Re: LBR function result codes still not available

    On Mon, 02 Jun 2008 11:10:49 -0700, Rich Jordan wrote:

    > On Jun 1, 2:35 pm, JF Mezei wrote:
    >> Tom Linden wrote:
    >> > And they should ALWAYS be expressed in SDL and made available through
    >> > starlet.

    >>
    >> I would suspect that resources have been limited ever since the Palmer
    >> days and they never saw any priority to finish the original work of
    >> building the SDL stuff for the library routines which they probably
    >> thought nobody used.
    >>
    >> Note that the routines to get the information about a library (forget
    >> the name) is ill defined and documentation lacks a LOT of the
    >> information necessary to produce the equivalent of LIBRARY/LIST/FULL.
    >> There is documentation on how to get the history, but no documentation
    >> of what the history record formats are.
    >>
    >> Looks to me like they abandonned the "publishing" process of the library
    >> routines halfway through and never came back to it. And these days,
    >> their focus is on supporting new HP hardware, it is very doubtful they
    >> will come back to stuff dating back from late 1980s.

    >
    > The documentation specifies that the return codes are defined in
    > $LBRDEF. I suppose at this point a new bug report would be more
    > likely to get that reference removed from the documentation than
    > getting the startlet files updates appropriately.
    >
    > I'll agree that the LBR function documentation leaves much to be
    > desired. Our task has been redefined to just use the librarian from
    > DCL; it took too much time trying to get the LBR functions working.
    > We're losing a little of the flexibility we wanted but the main
    > functionality will be just fine.


    Are you saying the LBR functions are NOT working?

    I may be missing something here, but I can't understand why it should take
    more than a few hours to create SDL sources for the entry point
    declarations
    and return codes.

    --
    PL/I for OpenVMS
    www.kednos.com

  18. Re: LBR function result codes still not available

    On Jun 3, 8:26 am, "Tom Linden" wrote:
    > On Mon, 02 Jun 2008 11:10:49 -0700, Rich Jordan wrote:
    > > On Jun 1, 2:35 pm, JF Mezei wrote:
    > >> Tom Linden wrote:
    > >> > And they should ALWAYS be expressed in SDL and made available through
    > >> > starlet.

    >
    > >> I would suspect that resources have been limited ever since the Palmer
    > >> days and they never saw any priority to finish the original work of
    > >> building the SDL stuff for the library routines which they probably
    > >> thought nobody used.

    >
    > >> Note that the routines to get the information about a library (forget
    > >> the name) is ill defined and documentation lacks a LOT of the
    > >> information necessary to produce the equivalent of LIBRARY/LIST/FULL.
    > >> There is documentation on how to get the history, but no documentation
    > >> of what the history record formats are.

    >
    > >> Looks to me like they abandonned the "publishing" process of the library
    > >> routines halfway through and never came back to it. And these days,
    > >> their focus is on supporting new HP hardware, it is very doubtful they
    > >> will come back to stuff dating back from late 1980s.

    >
    > > The documentation specifies that the return codes are defined in
    > > $LBRDEF. I suppose at this point a new bug report would be more
    > > likely to get that reference removed from the documentation than
    > > getting the startlet files updates appropriately.

    >
    > > I'll agree that the LBR function documentation leaves much to be
    > > desired. Our task has been redefined to just use the librarian from
    > > DCL; it took too much time trying to get the LBR functions working.
    > > We're losing a little of the flexibility we wanted but the main
    > > functionality will be just fine.

    >
    > Are you saying the LBR functions are NOT working?
    >
    > I may be missing something here, but I can't understand why it should take
    > more than a few hours to create SDL sources for the entry point
    > declarations
    > and return codes.
    >
    > --
    > PL/I for OpenVMSwww.kednos.com


    Nope. But its taken too long to get them working and I got tapped on
    the shoulder and told to do it the quick and dirty DCL way for now.

    FWIW I am not a programmer; I code on the side when the programmers
    are too busy. Thats what this task is. And the powers that be did
    not want an 'unsupported' 'could change' (even if it likely never
    will) workaround for something that should be there but isn't.

    Rich

  19. Re: LBR function result codes still not available

    Tom Linden wrote:

    > Are you saying the LBR functions are NOT working?


    Some of them provide useless results because the format of the output is
    not documented (getting hostory records for a module for instance).


    > I may be missing something here, but I can't understand why it should take
    > more than a few hours to create SDL sources for the entry point
    > declarations
    > and return codes.


    But countless comittees, powerpoint recommendations, hiring of a
    management consulting firm to study the cost/benefit of such a large
    project, and when they put all those costs out, they will conclude it
    isn't worth assigning man hours to generate the SDL version of the
    library function return codes.

    Unless a large customer (isn't DOD the last large customer left ?) comes
    forth and tells HP that they must generate the SDL for the library codes
    otherwise DID stop buying from HP, HP isn't going to do it.

+ Reply to Thread