Loading ...
Sorry, an error occurred while loading the content.
 

Re: SEASIK 1.0 released

Expand Messages
  • kerravon86
    ... Um, even if that were true, what does that have to do with the question on what the best way to implement C on MVS? And ported PDPCLIB to what? S/390? For
    Message 1 of 50 , Jun 1, 2010
      --- In hercules-os380@yahoogroups.com, Gerhard Postpischil <gerhardp@...> wrote:
      >
      > On 5/31/2010 7:10 PM, kerravon86 wrote:
      > > What people expect from a C program. What IBM
      > > implemented for their C compiler. What is
      > > currently implemented in PDPCLIB.
      >
      > You do realize that had the same effort been expended on
      > modifying PDPCLIB to run on bare metal, you could have ported
      > the kernel of any free distribution by now and not have to
      > bother any MVS people?

      Um, even if that were true, what does that have to
      do with the question on what the best way to
      implement C on MVS?

      And ported PDPCLIB to what? S/390? For what purpose?

      And really it is outside PDPCLIB's scope to run on
      bare metal. That would require all OS functionality
      to go inside every program.

      The closest I have to that is PDOS which does indeed
      run on the 386 metal. But even then I put OS
      functionality into PDOS not PDPCLIB.

      Perhaps I'm a stickler for convention, but I do
      roughly agree with the concept of separating OS
      functionality from C runtime functionality.

      BFN. Paul.
    • kerravon86
      ... ADRDSSU can t directly read the output of DSSRENAM, even if you specify DCB information. That s because ADRDSSU doesn t deal with RDW files (but DSSRENAM
      Message 50 of 50 , Aug 12, 2011
        --- In hercules-os380@yahoogroups.com, "Lutz" <dedvg158@...> wrote:
        >
        > > You could argue that the documentation in PDPCLIB
        > > for DSSRENAM is inadequate, with no example JCL
        > > or anything. That is true (and makeutil-1_0 seems
        > > to be plugging that gap). On the other hand, I
        > > try to make my programs self-documenting, in that
        > > they print their usage if the program is run
        > > without parameters. Some things like the RDW
        > > concept are documented separately as part of the
        > > S/380 documentation..
        >
        > In general nothing, but my job doesn't contain
        > DCBs for the DSSRENAM output dataset. The Datasets
        > created by DSSRENAM look like the input dataset,
        > but ADRDSSU can't read it.

        ADRDSSU can't directly read the output of DSSRENAM,
        even if you specify DCB information. That's because
        ADRDSSU doesn't deal with RDW files (but DSSRENAM
        does).

        > > ... what did your job do wrong? ie what was the
        > > difference between your job and the one that
        > > worked?
        >
        > The sample DSSRENAM.jcl contain DCBs, and everything works well.

        Your one with default DCB info (ie RECFM=U) should
        work well too. You still need to convert it into a
        RECFM=VB file though, e.g. by running COPYFILE.

        BFN. Paul.
      Your message has been successfully submitted and would be delivered to recipients shortly.