VS LOADER

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

VS LOADER

Hercules390 - Mvs mailing list
Hello H390-MVS list,

sorry for this (maybe) beginners question;

I am building compile, link and go procedures for the
new Stanford Pascal compiler, and I don't know how I can
enter INCLUDE statements to the VS LOADER (when there is
no linkage editor step). Is this possible?

When linking the Pascal program and building a load module,
I have to add these control statements

   ENTRY $PASENT
   INCLUDE SYSLIB(PASMONN)
   INCLUDE SYSLIB(PASLIBX)

to the linkage editor step; PASMONN is the Pascal runtime,
and PASLIBX contains additional runtime procedures, which are
needed in many Pascal programs. This works without problems.

If I want to run the Pascal programs directly from the object file
(without building a load module), the loader would have to add
the external entries in the same way. But I was not successful so far;
I get messages like this:

OPTIONS USED - PRINT,NOMAP,NOLET,CALL,RES,NOTERM,SIZE=307200,NAME=**GO
IEW1141    ENTRY $PASENT
IEW1141    INCLUDE SYSLIB(PASMONN)
IEW1141    INCLUDE SYSLIB(PASLIBX)
IEW1012  $PASCSP
IEW1012  $PASENT
   TOTAL LENGTH     2338
   ENTRY ADDRESS   AC010
IEW1141    WARNING - CARD RECEIVED NOT AN OBJECT RECORD
IEW1012    ERROR - UNRESOLVED EXTERNAL REFERENCE

I tried to enter the control statements using DDNAME SYSLIN, much the
same way
as I do it when using the linkage editor; but that seems to be wrong.

Can it be done? What is the right way to do it?

Another question:

at the moment - due to some technical reason - I force the users to
store their
Pascal programs in members of PO datasets; in fact, I need a (system wide)
unique member name to know where to store the Debug information for the
Pascal program. This means that a typical compile and go step would look
like this:

//PASCALN6 JOB (PASCAL),'TEST KALENDER',CLASS=A,MSGCLASS=X,
//             TIME=1440,REGION=8000K,MSGLEVEL=(1,1)
//*
//COMPGO   EXEC PASNCLG,MEM=KALENDER,
//         SRC='PASCALN.TESTPGM.PAS',
//         MOD='PASCALN.TESTPGM.LOAD'
//GO.INPUT DD  *
2017
//GO.DRUCKER DD SYSOUT=A

What do you think about such a restriction? Is this acceptable?
Instream source files will not be possible this way.

The good thing is: the Debug information can be located automatically
at run time, if there is some problem inside the module; this is true even
if your program consists of multiple sources; every function or procedure
knows where its debug information can be found (there is one debug
repository
- a PDS with many members - for the whole system; the member names of
the debug repository are the same as the source member names).

The Debug repository is allocated automatically, when using the procedures
PASNCxx etc. (some work still has to be done on MVS; on CMS, it works
this way, already).

I would like to get some feedback on this,
thank you

Kind regards

Bernd


Reply | Threaded
Open this post in threaded view
|

Re: VS LOADER

Hercules390 - Mvs mailing list
Hello H390-MVS list,

first question answered by myself :-)

I omitted the INCLUDE statements and instead added the object files
in the correct order to SYSLIN (PASMONN, which contains $PASENT, first).

That did the trick:

//GO       EXEC PGM=LOADER,COND=((4,LT,COMPILE),(0,LT,POSTPROC)),
// PARM='/TIME=&GOTIME,&GOPARM',REGION=&GOREG
//STEPLIB  DD  DISP=SHR,DSN=&HLQ..COMPILER.LOAD  (NEEDED FOR K+ ONLY)
//SYSLIN   DD  DISP=SHR,DSN=&HLQ..RUNTIME.TEXT(PASMONN)
//         DD  DISP=SHR,DSN=&HLQ..RUNTIME.TEXT(PASLIBX)
//         DD  DISP=(OLD,DELETE),DSN=&&OBJF
//         DD  DDNAME=SYSLIN2
//SYSLOUT  DD  SYSOUT=&SOUT
//SYSLIB   DD  DISP=SHR,DSN=&HLQ..RUNTIME.TEXT
//         DD  DISP=SHR,DSN=&HLQ..COMPILER.TEXT
//         DD  DISP=SHR,DSN=SYS1.FORTLIB
//DBGINFO  DD  DISP=SHR,DSN=&HLQ..DBGINFO
//INPUT    DD  DDNAME=SYSIN
//OUTPUT   DD  SYSOUT=&SOUT
//FT06F001 DD  SYSOUT=&SOUT
//PASTRACE DD  SYSOUT=&SOUT
//SYSUDUMP DD  SYSOUT=&SOUT

now all 4 procedures (PASNC, PASNCL, PASNCG and PASNCLG)
work as expected.

I still would love to get some feedback to my second question.

Thanks,
kind regards

Bernd



Am 13.04.2017 um 14:06 schrieb Bernd Oppolzer [hidden email]
[H390-MVS]:

>
> Hello H390-MVS list,
>
> sorry for this (maybe) beginners question;
>
> I am building compile, link and go procedures for the
> new Stanford Pascal compiler, and I don't know how I can
> enter INCLUDE statements to the VS LOADER (when there is
> no linkage editor step). Is this possible?
>
> When linking the Pascal program and building a load module,
> I have to add these control statements
>
> ENTRY $PASENT
> INCLUDE SYSLIB(PASMONN)
> INCLUDE SYSLIB(PASLIBX)
>
> to the linkage editor step; PASMONN is the Pascal runtime,
> and PASLIBX contains additional runtime procedures, which are
> needed in many Pascal programs. This works without problems.
>
> If I want to run the Pascal programs directly from the object file
> (without building a load module), the loader would have to add
> the external entries in the same way. But I was not successful so far;
> I get messages like this:
>
> OPTIONS USED - PRINT,NOMAP,NOLET,CALL,RES,NOTERM,SIZE=307200,NAME=**GO
> IEW1141 ENTRY $PASENT
> IEW1141 INCLUDE SYSLIB(PASMONN)
> IEW1141 INCLUDE SYSLIB(PASLIBX)
> IEW1012 $PASCSP
> IEW1012 $PASENT
> TOTAL LENGTH 2338
> ENTRY ADDRESS AC010
> IEW1141 WARNING - CARD RECEIVED NOT AN OBJECT RECORD
> IEW1012 ERROR - UNRESOLVED EXTERNAL REFERENCE
>
> I tried to enter the control statements using DDNAME SYSLIN, much the
> same way
> as I do it when using the linkage editor; but that seems to be wrong.
>
> Can it be done? What is the right way to do it?
>
> Another question:
>
> at the moment - due to some technical reason - I force the users to
> store their
> Pascal programs in members of PO datasets; in fact, I need a (system wide)
> unique member name to know where to store the Debug information for the
> Pascal program. This means that a typical compile and go step would look
> like this:
>
> //PASCALN6 JOB (PASCAL),'TEST KALENDER',CLASS=A,MSGCLASS=X,
> // TIME=1440,REGION=8000K,MSGLEVEL=(1,1)
> //*
> //COMPGO EXEC PASNCLG,MEM=KALENDER,
> // SRC='PASCALN.TESTPGM.PAS',
> // MOD='PASCALN.TESTPGM.LOAD'
> //GO.INPUT DD *
> 2017
> //GO.DRUCKER DD SYSOUT=A
>
> What do you think about such a restriction? Is this acceptable?
> Instream source files will not be possible this way.
>
> The good thing is: the Debug information can be located automatically
> at run time, if there is some problem inside the module; this is true even
> if your program consists of multiple sources; every function or procedure
> knows where its debug information can be found (there is one debug
> repository
> - a PDS with many members - for the whole system; the member names of
> the debug repository are the same as the source member names).
>
> The Debug repository is allocated automatically, when using the procedures
> PASNCxx etc. (some work still has to be done on MVS; on CMS, it works
> this way, already).
>
> I would like to get some feedback on this,
> thank you
>
> Kind regards
>
> Bernd
>
>

Reply | Threaded
Open this post in threaded view
|

Re: VS LOADER

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
On 4/13/2017 8:06 AM, Bernd Oppolzer [hidden email] [H390-MVS]
wrote:

> OPTIONS USED - PRINT,NOMAP,NOLET,CALL,RES,NOTERM,SIZE=307200,NAME=**GO
> IEW1141    ENTRY $PASENT
> IEW1141    INCLUDE SYSLIB(PASMONN)
> IEW1141    INCLUDE SYSLIB(PASLIBX)
> IEW1012  $PASCSP
> IEW1012  $PASENT
>     TOTAL LENGTH     2338
>     ENTRY ADDRESS   AC010
> IEW1141    WARNING - CARD RECEIVED NOT AN OBJECT RECORD
> IEW1012    ERROR - UNRESOLVED EXTERNAL REFERENCE

I stopped using the LOADER in the seventies when I realized that it
produced unusable dumps during SYSLIB must be either all load-modules or
all object deck format. Object decks would be on SYSLIN; I don't recall
whether they're supported on SYSLIB.

INCLUDE cards should not be necessary if the decks you need to be
included (from SYSLIB) have names or alias names that are needed (not
that you have the CALL option on).  Perhaps the compiler can be extended
to support or produce the ENTRY (object deck END card), and something
like the assembler PUNCH card.

I just found an XA copy of the Linkage Editor/Loader manual. For the loader:

1) Only four DD names are supported: SYSLIN, SYSLOUT, SYSLIB, SYSTERM.
SYSLIN is the only required one.

2) SYSLIB may specify one or more (concatenated) PDSs, but they all must
contain onkly object modules or only load modules.

3) INCLUDE cards are ignored. It doesn't mention ENTRY cards, but
documents an EP= PARM option.


> I tried to enter the control statements using DDNAME SYSLIN, much the
> same way
> as I do it when using the linkage editor; but that seems to be wrong.
>
> Can it be done? What is the right way to do it?

Everything needed must be resolved by automatic CALL resolution.

> Another question:
>
> at the moment - due to some technical reason - I force the users to
> store their
> Pascal programs in members of PO datasets; in fact, I need a (system wide)
> unique member name to know where to store the Debug information for the
> Pascal program. This means that a typical compile and go step would look
> like this:
>
> //PASCALN6 JOB (PASCAL),'TEST KALENDER',CLASS=A,MSGCLASS=X,
> //             TIME=1440,REGION=8000K,MSGLEVEL=(1,1)
> //*
> //COMPGO   EXEC PASNCLG,MEM=KALENDER,
> //         SRC='PASCALN.TESTPGM.PAS',
> //         MOD='PASCALN.TESTPGM.LOAD'
> //GO.INPUT DD  *
> 2017
> //GO.DRUCKER DD SYSOUT=A
>
> What do you think about such a restriction? Is this acceptable?
> Instream source files will not be possible this way.

I cheat - my huge (assembler) test PROC has an IEBUPDTX step to allow
inline source, and the program it feeds into has the option of including
source from PDSs. (Program ASMANY in cbt file 860). You could also use
an IEBGENER step (in a test PROC) to copy SYSIN.

> I would like to get some feedback on this,
> thank you
The kt3/4- "standard" is to have compilers and compiler related data
sets either with a SYS1 or SYS2 index. Your compiler and support
programs could go into SYS2.LINKLIB, and the INCLUDE and debug members
into SYS2.PASLIB?


Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

Reply | Threaded
Open this post in threaded view
|

Re: VS LOADER

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
Creating the Pascal debug file based on the compile source (or even the destination file) will not work in the long term unless these files are optional and won't cause confusion. The problem is that the load members could be copied which would lose access to the debug file which may cause confusion and difficulties unless they are familiar  with the process. As an alternative, you could create the debug either as load modules  in the same library. I like IBM's GOFF implementation. One of the options was to include debug info directly in the load module.
Another alternative might be to store the debug file name in the load module but the drawback again is if files are copied or renamed.
Jon.

    On Thursday, April 13, 2017 5:35 AM, "Bernd Oppolzer [hidden email] [H390-MVS]" <[hidden email]> wrote:
 

      Hello H390-MVS list, first question answered by myself :-)
  now all 4 procedures (PASNC, PASNCL, PASNCG and PASNCLG) 
 work as expected.
  I still would love to get some feedback to my second question. 
 Another question:
 
 at the moment - due to some technical reason - I force the users to
 store their
 Pascal programs in members of PO datasets; in fact, I need a (system wide)
 unique member name to know where to store the Debug information for the
 Pascal program. This means that a typical compile and go step would look
 like this:
 
 //PASCALN6 JOB (PASCAL),'TEST KALENDER',CLASS=A,MSGCLASS=X,
 // TIME=1440,REGION=8000K,MSGLEVEL=(1,1)
 //*
 //COMPGO EXEC PASNCLG,MEM=KALENDER,
 // SRC='PASCALN.TESTPGM.PAS',
 // MOD='PASCALN.TESTPGM.LOAD'
 //GO.INPUT DD *
 2017
 //GO.DRUCKER DD SYSOUT=A
 
 What do you think about such a restriction? Is this acceptable?
 Instream source files will not be possible this way.
 
 The good thing is: the Debug information can be located automatically
 at run time, if there is some problem inside the module; this is true even
 if your program consists of multiple sources; every function or procedure
 knows where its debug information can be found (there is one debug
 repository
 - a PDS with many members - for the whole system; the member names of
 the debug repository are the same as the source member names).
 
 The Debug repository is allocated automatically, when using the procedures
 PASNCxx etc. (some work still has to be done on MVS; on CMS, it works
 this way, already).
 
 I would like to get some feedback on this,


   #yiv3010576395 #yiv3010576395 -- #yiv3010576395ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv3010576395 #yiv3010576395ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv3010576395 #yiv3010576395ygrp-mkp #yiv3010576395hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv3010576395 #yiv3010576395ygrp-mkp #yiv3010576395ads {margin-bottom:10px;}#yiv3010576395 #yiv3010576395ygrp-mkp .yiv3010576395ad {padding:0 0;}#yiv3010576395 #yiv3010576395ygrp-mkp .yiv3010576395ad p {margin:0;}#yiv3010576395 #yiv3010576395ygrp-mkp .yiv3010576395ad a {color:#0000ff;text-decoration:none;}#yiv3010576395 #yiv3010576395ygrp-sponsor #yiv3010576395ygrp-lc {font-family:Arial;}#yiv3010576395 #yiv3010576395ygrp-sponsor #yiv3010576395ygrp-lc #yiv3010576395hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv3010576395 #yiv3010576395ygrp-sponsor #yiv3010576395ygrp-lc .yiv3010576395ad {margin-bottom:10px;padding:0 0;}#yiv3010576395 #yiv3010576395actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv3010576395 #yiv3010576395activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv3010576395 #yiv3010576395activity span {font-weight:700;}#yiv3010576395 #yiv3010576395activity span:first-child {text-transform:uppercase;}#yiv3010576395 #yiv3010576395activity span a {color:#5085b6;text-decoration:none;}#yiv3010576395 #yiv3010576395activity span span {color:#ff7900;}#yiv3010576395 #yiv3010576395activity span .yiv3010576395underline {text-decoration:underline;}#yiv3010576395 .yiv3010576395attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv3010576395 .yiv3010576395attach div a {text-decoration:none;}#yiv3010576395 .yiv3010576395attach img {border:none;padding-right:5px;}#yiv3010576395 .yiv3010576395attach label {display:block;margin-bottom:5px;}#yiv3010576395 .yiv3010576395attach label a {text-decoration:none;}#yiv3010576395 blockquote {margin:0 0 0 4px;}#yiv3010576395 .yiv3010576395bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv3010576395 .yiv3010576395bold a {text-decoration:none;}#yiv3010576395 dd.yiv3010576395last p a {font-family:Verdana;font-weight:700;}#yiv3010576395 dd.yiv3010576395last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv3010576395 dd.yiv3010576395last p span.yiv3010576395yshortcuts {margin-right:0;}#yiv3010576395 div.yiv3010576395attach-table div div a {text-decoration:none;}#yiv3010576395 div.yiv3010576395attach-table {width:400px;}#yiv3010576395 div.yiv3010576395file-title a, #yiv3010576395 div.yiv3010576395file-title a:active, #yiv3010576395 div.yiv3010576395file-title a:hover, #yiv3010576395 div.yiv3010576395file-title a:visited {text-decoration:none;}#yiv3010576395 div.yiv3010576395photo-title a, #yiv3010576395 div.yiv3010576395photo-title a:active, #yiv3010576395 div.yiv3010576395photo-title a:hover, #yiv3010576395 div.yiv3010576395photo-title a:visited {text-decoration:none;}#yiv3010576395 div#yiv3010576395ygrp-mlmsg #yiv3010576395ygrp-msg p a span.yiv3010576395yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv3010576395 .yiv3010576395green {color:#628c2a;}#yiv3010576395 .yiv3010576395MsoNormal {margin:0 0 0 0;}#yiv3010576395 o {font-size:0;}#yiv3010576395 #yiv3010576395photos div {float:left;width:72px;}#yiv3010576395 #yiv3010576395photos div div {border:1px solid #666666;height:62px;overflow:hidden;width:62px;}#yiv3010576395 #yiv3010576395photos div label {color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv3010576395 #yiv3010576395reco-category {font-size:77%;}#yiv3010576395 #yiv3010576395reco-desc {font-size:77%;}#yiv3010576395 .yiv3010576395replbq {margin:4px;}#yiv3010576395 #yiv3010576395ygrp-actbar div a:first-child {margin-right:2px;padding-right:5px;}#yiv3010576395 #yiv3010576395ygrp-mlmsg {font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv3010576395 #yiv3010576395ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv3010576395 #yiv3010576395ygrp-mlmsg select, #yiv3010576395 input, #yiv3010576395 textarea {font:99% Arial, Helvetica, clean, sans-serif;}#yiv3010576395 #yiv3010576395ygrp-mlmsg pre, #yiv3010576395 code {font:115% monospace;}#yiv3010576395 #yiv3010576395ygrp-mlmsg * {line-height:1.22em;}#yiv3010576395 #yiv3010576395ygrp-mlmsg #yiv3010576395logo {padding-bottom:10px;}#yiv3010576395 #yiv3010576395ygrp-msg p a {font-family:Verdana;}#yiv3010576395 #yiv3010576395ygrp-msg p#yiv3010576395attach-count span {color:#1E66AE;font-weight:700;}#yiv3010576395 #yiv3010576395ygrp-reco #yiv3010576395reco-head {color:#ff7900;font-weight:700;}#yiv3010576395 #yiv3010576395ygrp-reco {margin-bottom:20px;padding:0px;}#yiv3010576395 #yiv3010576395ygrp-sponsor #yiv3010576395ov li a {font-size:130%;text-decoration:none;}#yiv3010576395 #yiv3010576395ygrp-sponsor #yiv3010576395ov li {font-size:77%;list-style-type:square;padding:6px 0;}#yiv3010576395 #yiv3010576395ygrp-sponsor #yiv3010576395ov ul {margin:0;padding:0 0 0 8px;}#yiv3010576395 #yiv3010576395ygrp-text {font-family:Georgia;}#yiv3010576395 #yiv3010576395ygrp-text p {margin:0 0 1em 0;}#yiv3010576395 #yiv3010576395ygrp-text tt {font-size:120%;}#yiv3010576395 #yiv3010576395ygrp-vital ul li:last-child {border-right:none !important;}#yiv3010576395
Reply | Threaded
Open this post in threaded view
|

Pascal Debug information (was : VS LOADER)

Hercules390 - Mvs mailing list
Thank you for your comment.

To make things a little more clear:

only the member name of the source file is stored in the
executable object (every procedure has the member name
of the source file in some sort of appendix, which can be found
from the entry point address - much the same way as today's
PPA1 control blocks).

If an error occurs, the PASSNAP routine tries to write a Snap Dump;
it reconstructs the call stack from the save area trace and from the
entry points it gets the source member names. Using DD:DBGINFO,
it looks for a member with that name which has the debug information
(especially: which Pascal variable - name and datatype - is at what
position in the runtime stack or in the STATIC CSECT which is associated
with that procedure). If it finds the DBGINFO member, it can print
the variables in Pascal notation; if not, it prints the area in hex.

So the debug information indeed is optional; the call stack with
the procedure names will be printed in any case. The line information
depends on an offset to line translation table, which is part of the
load module (in the debug case), so that's another story.

You can copy the load modules freely without losing the connection
to the debug information; all you need is the DBGINFO dataset, which
is ONE CENTRALIZED dataset per environment (test, production).

The concept is not new, BTW; it existed already in the 1979 Stanford
Pascal compiler. I only added support for applications which consist
of multiple sources; because every function or procedure now tells
from which source it has been built, it also refers to the right DBGINFO
member, and so PASSNAP is able to print variables in Pascal notation
not only for the mainline procedure but for all procedures in the
(multi-source) application.

In fact, this works only for CMS at the moment;

by issuing CMS FILEDEF internally, PASSNAP reads the needed DBGINFO
file on an as-needed base, when it encounters the source file names
during save-area walk-up.

I still have to do the same for MVS, and that means: read the member
from DD:DBGINFO, with member name known at runtime ...

I would like any hints, how this can be done easily ...
dynamic allocation, or are there easier methods?
DDName DBGINFO is fixed, only the member name (= sourcefile name)
is variable ...

Thank you,
kind regards

Bernd


from https://www.facebook.com/StanfordPascal/?ref=aymt_homepage_panel:


Watch this:

without PASSNAP, you get this kind of runtime error report (the FIBDEMO
example from the 1979 Stanford paper, tested with the current compiler):

EXEC PASRUN FIBDEMO
fibonacci # 10 is

**** RUN ERROR AT LOCATION : 000000D4 OF PROCEDURE : FIBONACCI

**** ERROR CODE IS 1002 : SUBRANGE VALUE OUT OF RANGE
**** THE OFFENDING VALUE : -1 IS NOT IN THE RANGE : 0 30

**** FIBONACCI WAS CALLED BY : FIBONACCI
**** FIBONACCI WAS CALLED BY : FIBONACCI
**** FIBONACCI WAS CALLED BY : FIBONACCI
**** FIBONACCI WAS CALLED BY : FIBONACCI
**** FIBONACCI WAS CALLED BY : FIBONACCI
**** FIBONACCI WAS CALLED BY : FIBONACCI
**** FIBONACCI WAS CALLED BY : FIBONACCI
**** FIBONACCI WAS CALLED BY : FIBONACCI
**** FIBONACCI WAS CALLED BY : $PASMAIN

+++ R(01102) +++
Ready; T=0.04/0.11 22:32:08

... limited, but useful anyway.

With PASSNAP added (linked to your program), you get:

EXEC PASRUN FIBDEMO PASSNAP
fibonacci # 10 is
*************************
***** SNAPSHOT DUMP *****
*************************

**** SNAPSHOT WAS CALLED BY --> PASCAL_MONITOR

**** RUN ERROR: 1002 FROM LINE: 37 OF PROCEDURE FIBONACCI
EPA address of FIBONACCI is 000205B8
Error offset is 00D4

**** SUBRANGE VALUE IS OUT OF RANGE.

**** THE OFFENDING VALUE: -1 IS NOT IN THE RANGE: 0..30

**** VARIABLES FOR FIBONACCI ****
Stack at address 00031770
Static variables at address 000205A0

J (A/0070/000317E0) = 2
ANZCALL (S/0010/000205B0) = 10

**** PROCEDURE FIBONACCI WAS CALLED BY --> FIBONACCI
FROM LINE: 37
EPA address of FIBONACCI is 000205B8
Call offset is 00B8

**** VARIABLES FOR FIBONACCI ****
Stack at address 000316F8
Static variables at address 000205A0

J (A/0070/00031768) = 3
ANZCALL (S/0010/000205B0) = 10

**** PROCEDURE FIBONACCI WAS CALLED BY --> FIBONACCI
FROM LINE: 37

etc. etc.

that is:

- line information from the source files added
- variables printed at every procedure level in Pascal notation
- addresses of relevant areas in hex

At the moment, PASSNAP only runs on the CMS target, not on MVS (will
follow soon) and not on Windows - OS/2 - Linux (may follow later).




Am 13.04.2017 um 15:38 schrieb Jon Perryman [hidden email] [H390-MVS]:

> Creating the Pascal debug file based on the compile source (or even
> the destination file) will not work in the long term unless these
> files are optional and won't cause confusion. The problem is that the
> load members could be copied which would lose access to the debug file
> which may cause confusion and difficulties unless they are familiar
>  with the process. As an alternative, you could create the debug
> either as load modules  in the same library. I like IBM's GOFF
> implementation. One of the options was to include debug info directly
> in the load module.
>
> Another alternative might be to store the debug file name in the load
> module but the drawback again is if files are copied or renamed.
>
> Jon.
>

Reply | Threaded
Open this post in threaded view
|

Re: VS LOADER

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
On 13 April 2017 at 09:38, Jon Perryman [hidden email] wrote:

> As an alternative, you could create the debug either as load modules  in
> the same library. I like IBM's GOFF implementation. One of the options was
> to include debug info directly in the load module.


Are you speaking of the Binder and Program Objects on z/OS? Or does GOFF
really have some scheme to include debug info (we're not talking of .SYM
records, I assume) in the GOFF object and then the load module?

Tony H.
Reply | Threaded
Open this post in threaded view
|

Re: Pascal Debug information (was : VS LOADER)

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
On 4/13/2017 10:58 AM, Bernd Oppolzer [hidden email] [H390-MVS]
wrote:
> If an error occurs, the PASSNAP routine tries to write a Snap Dump;
> it reconstructs the call stack from the save area trace and from the
> entry points it gets the source member names. Using DD:DBGINFO,
> it looks for a member with that name which has the debug information
> (especially: which Pascal variable - name and datatype - is at what
> position in the runtime stack or in the STATIC CSECT which is associated
> with that procedure). If it finds the DBGINFO member, it can print
> the variables in Pascal notation; if not, it prints the area in hex.

In that case, you don't need dynamic allocation.

1) Check for the existence of the required DD:

        DEVTYPE BUGPDS+DCBDDNAM-IHADCB,RESULT (needs DCBD mapping)

if R15 is not zero, or RESULT+2 is not X'20' (UCB3DACC), the file is not
present or usable.

BUGPDS   DCB   DDNAME=DBGINFO,MACRF=R,DSORG=PO,EODAD=endfile

Open BUGPDS for inout, and check for member with
        FIND BUGPDS,memname

The rest is in the details <g>   Using BPAM requires you to do your own
unblocking, or you could establish a QSAM DCB, and modify the JFCB with
the member name.

Many years ago Gilbert Saint-Flour (R.I.P.) contributed a SYSDEBUG
module CBT429.FILE183 (on the optional CBT packs) that does very nice
trace backs, save area formatting, etc. While it doesn't format
variables, it has nice features.

I have a very specific module that formats assembler generated SYM
cards, matches them to storage, and prints the variable data. You might
check whether the same format is used - if so, it might make sense to
dispense with the debug PDS and keep the SYM information in the load
module (it only uses disk space; it's mot loaded into storage). Using
the common format may allow other debug programs to work.
       

Concerning the PROCs, I would recommend not the explicit specification
of the names, but only two index levels:

// EXEC PASTEST,INDEX=HERC01,PROJECT=XYZ,MEMBER='?'

or something similar (I use HIX for high-level index, and MEM for
member). Or you could use the (misleading) ISPF/RFE terminology of
PROJECT/LIBRARY/TYPE. The other portions would be fixed; i.e.,

//SYSIN DD DISP=SHR,DSN=&INDEX.&PROJECT..SRC(&MEMBER)


Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

Reply | Threaded
Open this post in threaded view
|

Re: VS LOADER

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
---In [hidden email], <berndoppolzer@...> wrote :

> ENTRY $PASENT

Note that you don't need an ENTRY
statement if:

1. You end the assembler source file
that contains $PASENT with:

END $PASENT

instead of just:

END.

2. You use object code instead of
NCAL linker output.

> INCLUDE SYSLIB(PASMONN)

You also don't need this if you have
an appropriate set of aliases.

E.g. if PASMONN contains a function
called PASREAD, and $PASENT
calls PASREAD, then an alias of
PASREAD pointing to PASMONN
will ensure that PASMONN is linked in.

Note that I wasn't even aware that
a loader existed. What is the module
name of the loader? The linker is
IEWL, which is all that I have ever used.

BFN. Paul.
Reply | Threaded
Open this post in threaded view
|

Re: VS LOADER

Hercules390 - Mvs mailing list
 - - - In [hidden email], <kerravon86@...> wrote:
 - - - beginning snipped - - -
> Note that I wasn't even aware that
>a loader existed. What is the module
>name of the loader? The linker is
>IEWL, which is all that I have ever used.
> BFN. Paul.

Loader's name is PGM=LOADER

I prefer using ASMFCLG instead of ASMFCG

On my various programs and sub-routines,
I never put a name on each or any END statement.
Just a comma to separate from any comment.
Reply | Threaded
Open this post in threaded view
|

Re: VS LOADER

Hercules390 - Mvs mailing list
On 4/13/2017 10:49 PM, [hidden email] [H390-MVS] wrote:

> Loader's name is PGM=LOADER

Strictly speaking, the name is IEWLDRGO, and LOADER is an alias <g>

> On my various programs and sub-routines,
> I never put a name on each or any END statement.
> Just a comma to separate from any comment.
Ditto. The disassembler is the only code I run that needs an entry,
because the first CSECT isn't it.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

Reply | Threaded
Open this post in threaded view
|

Re: VS LOADER

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
I was referring to the HLASM and IBM C GOFF option. I used it in conjunction with XDC so I'm not sure about the implementation specifics but in team environments separate debug files were a nuisance. Better would have been if XDC could have used it from a separate load module in the same library but at least it was easy to keep things in sync when dealing with others.
Jon.
On Thursday, April 13, 2017 9:36 AM, "Tony Harminc [hidden email] [H390-MVS]" <[hidden email]> wrote:


     On 13 April 2017 at 09:38, Jon Perryman [hidden email]  wrote:

As an alternative, you could create the debug either as load modules  in the same library. I like IBM's GOFF implementation. One of the options was to include debug info directly in the load module.

Are you speaking of the Binder and Program Objects on z/OS? Or does GOFF really have some scheme to include debug info (we're not talking of .SYM records, I assume) in the GOFF object and then the load module?

Tony H.
  #yiv9169105555 #yiv9169105555 -- #yiv9169105555ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv9169105555 #yiv9169105555ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv9169105555 #yiv9169105555ygrp-mkp #yiv9169105555hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv9169105555 #yiv9169105555ygrp-mkp #yiv9169105555ads {margin-bottom:10px;}#yiv9169105555 #yiv9169105555ygrp-mkp .yiv9169105555ad {padding:0 0;}#yiv9169105555 #yiv9169105555ygrp-mkp .yiv9169105555ad p {margin:0;}#yiv9169105555 #yiv9169105555ygrp-mkp .yiv9169105555ad a {color:#0000ff;text-decoration:none;}#yiv9169105555 #yiv9169105555ygrp-sponsor #yiv9169105555ygrp-lc {font-family:Arial;}#yiv9169105555 #yiv9169105555ygrp-sponsor #yiv9169105555ygrp-lc #yiv9169105555hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv9169105555 #yiv9169105555ygrp-sponsor #yiv9169105555ygrp-lc .yiv9169105555ad {margin-bottom:10px;padding:0 0;}#yiv9169105555 #yiv9169105555actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv9169105555 #yiv9169105555activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv9169105555 #yiv9169105555activity span {font-weight:700;}#yiv9169105555 #yiv9169105555activity span:first-child {text-transform:uppercase;}#yiv9169105555 #yiv9169105555activity span a {color:#5085b6;text-decoration:none;}#yiv9169105555 #yiv9169105555activity span span {color:#ff7900;}#yiv9169105555 #yiv9169105555activity span .yiv9169105555underline {text-decoration:underline;}#yiv9169105555 .yiv9169105555attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv9169105555 .yiv9169105555attach div a {text-decoration:none;}#yiv9169105555 .yiv9169105555attach img {border:none;padding-right:5px;}#yiv9169105555 .yiv9169105555attach label {display:block;margin-bottom:5px;}#yiv9169105555 .yiv9169105555attach label a {text-decoration:none;}#yiv9169105555 blockquote {margin:0 0 0 4px;}#yiv9169105555 .yiv9169105555bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv9169105555 .yiv9169105555bold a {text-decoration:none;}#yiv9169105555 dd.yiv9169105555last p a {font-family:Verdana;font-weight:700;}#yiv9169105555 dd.yiv9169105555last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv9169105555 dd.yiv9169105555last p span.yiv9169105555yshortcuts {margin-right:0;}#yiv9169105555 div.yiv9169105555attach-table div div a {text-decoration:none;}#yiv9169105555 div.yiv9169105555attach-table {width:400px;}#yiv9169105555 div.yiv9169105555file-title a, #yiv9169105555 div.yiv9169105555file-title a:active, #yiv9169105555 div.yiv9169105555file-title a:hover, #yiv9169105555 div.yiv9169105555file-title a:visited {text-decoration:none;}#yiv9169105555 div.yiv9169105555photo-title a, #yiv9169105555 div.yiv9169105555photo-title a:active, #yiv9169105555 div.yiv9169105555photo-title a:hover, #yiv9169105555 div.yiv9169105555photo-title a:visited {text-decoration:none;}#yiv9169105555 div#yiv9169105555ygrp-mlmsg #yiv9169105555ygrp-msg p a span.yiv9169105555yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv9169105555 .yiv9169105555green {color:#628c2a;}#yiv9169105555 .yiv9169105555MsoNormal {margin:0 0 0 0;}#yiv9169105555 o {font-size:0;}#yiv9169105555 #yiv9169105555photos div {float:left;width:72px;}#yiv9169105555 #yiv9169105555photos div div {border:1px solid #666666;height:62px;overflow:hidden;width:62px;}#yiv9169105555 #yiv9169105555photos div label {color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv9169105555 #yiv9169105555reco-category {font-size:77%;}#yiv9169105555 #yiv9169105555reco-desc {font-size:77%;}#yiv9169105555 .yiv9169105555replbq {margin:4px;}#yiv9169105555 #yiv9169105555ygrp-actbar div a:first-child {margin-right:2px;padding-right:5px;}#yiv9169105555 #yiv9169105555ygrp-mlmsg {font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv9169105555 #yiv9169105555ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv9169105555 #yiv9169105555ygrp-mlmsg select, #yiv9169105555 input, #yiv9169105555 textarea {font:99% Arial, Helvetica, clean, sans-serif;}#yiv9169105555 #yiv9169105555ygrp-mlmsg pre, #yiv9169105555 code {font:115% monospace;}#yiv9169105555 #yiv9169105555ygrp-mlmsg * {line-height:1.22em;}#yiv9169105555 #yiv9169105555ygrp-mlmsg #yiv9169105555logo {padding-bottom:10px;}#yiv9169105555 #yiv9169105555ygrp-msg p a {font-family:Verdana;}#yiv9169105555 #yiv9169105555ygrp-msg p#yiv9169105555attach-count span {color:#1E66AE;font-weight:700;}#yiv9169105555 #yiv9169105555ygrp-reco #yiv9169105555reco-head {color:#ff7900;font-weight:700;}#yiv9169105555 #yiv9169105555ygrp-reco {margin-bottom:20px;padding:0px;}#yiv9169105555 #yiv9169105555ygrp-sponsor #yiv9169105555ov li a {font-size:130%;text-decoration:none;}#yiv9169105555 #yiv9169105555ygrp-sponsor #yiv9169105555ov li {font-size:77%;list-style-type:square;padding:6px 0;}#yiv9169105555 #yiv9169105555ygrp-sponsor #yiv9169105555ov ul {margin:0;padding:0 0 0 8px;}#yiv9169105555 #yiv9169105555ygrp-text {font-family:Georgia;}#yiv9169105555 #yiv9169105555ygrp-text p {margin:0 0 1em 0;}#yiv9169105555 #yiv9169105555ygrp-text tt {font-size:120%;}#yiv9169105555 #yiv9169105555ygrp-vital ul li:last-child {border-right:none !important;}#yiv9169105555

   
Reply | Threaded
Open this post in threaded view
|

Re: Pascal Debug information (was : VS LOADER)

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
Thank you, Gerhard, for your valuable suggestions,
I appreciate that and will check them out soon.

I forgot to mention that PASSNAP is written in Pascal completely;
it does all the save area checking etc. using only Pascal and it uses
Pascal I/O (which is based on QSAM) to read the DBGINFO files
and print the results.

So the challenge will be:

to extend the Pascal runtime (written in ASSEMBLER) in a way,
that opening a member with a name known at runtime is supported,
while maintaining the normal functions of Pascal I/O
(RESET, REWRITE, READ, WRITE, GET, PUT).

Of course, this can be done by offering a new Pascal function
(for example OPENPDS), which will be limited to the MVS version.
Or: I will check how Pascal/VS (from IBM) did it; I'm sure they had
a nice function for that, which was seamlessly integrated into the
Pascal runtime.

I'll keep you informed; that may take some time, because I still
have a money job.

For more details on the Pascal compiler (for example:
the PASSNAP source code - working only for CMS at the moment),
you may look here:

http://bernd-oppolzer.de/job9.htm

or here (some sort of developer's blog):

https://www.facebook.com/StanfordPascal/?ref=aymt_homepage_panel

Kind regards

Bernd



Am 13.04.2017 um 19:03 schrieb Gerhard Postpischil [hidden email]
[H390-MVS]:

>
> On 4/13/2017 10:58 AM, Bernd Oppolzer [hidden email] [H390-MVS]
> wrote:
> > If an error occurs, the PASSNAP routine tries to write a Snap Dump;
> > it reconstructs the call stack from the save area trace and from the
> > entry points it gets the source member names. Using DD:DBGINFO,
> > it looks for a member with that name which has the debug information
> > (especially: which Pascal variable - name and datatype - is at what
> > position in the runtime stack or in the STATIC CSECT which is associated
> > with that procedure). If it finds the DBGINFO member, it can print
> > the variables in Pascal notation; if not, it prints the area in hex.
>
> In that case, you don't need dynamic allocation.
>
> 1) Check for the existence of the required DD:
>
> DEVTYPE BUGPDS+DCBDDNAM-IHADCB,RESULT (needs DCBD mapping)
>
> if R15 is not zero, or RESULT+2 is not X'20' (UCB3DACC), the file is not
> present or usable.
>
> BUGPDS DCB DDNAME=DBGINFO,MACRF=R,DSORG=PO,EODAD=endfile
>
> Open BUGPDS for inout, and check for member with
> FIND BUGPDS,memname
>
> The rest is in the details <g> Using BPAM requires you to do your own
> unblocking, or you could establish a QSAM DCB, and modify the JFCB with
> the member name.
>
> Many years ago Gilbert Saint-Flour (R.I.P.) contributed a SYSDEBUG
> module CBT429.FILE183 (on the optional CBT packs) that does very nice
> trace backs, save area formatting, etc. While it doesn't format
> variables, it has nice features.
>
> I have a very specific module that formats assembler generated SYM
> cards, matches them to storage, and prints the variable data. You might
> check whether the same format is used - if so, it might make sense to
> dispense with the debug PDS and keep the SYM information in the load
> module (it only uses disk space; it's mot loaded into storage). Using
> the common format may allow other debug programs to work.
>
>
> Concerning the PROCs, I would recommend not the explicit specification
> of the names, but only two index levels:
>
> // EXEC PASTEST,INDEX=HERC01,PROJECT=XYZ,MEMBER='?'
>
> or something similar (I use HIX for high-level index, and MEM for
> member). Or you could use the (misleading) ISPF/RFE terminology of
> PROJECT/LIBRARY/TYPE. The other portions would be fixed; i.e.,
>
> //SYSIN DD DISP=SHR,DSN=&INDEX.&PROJECT..SRC(&MEMBER)
>
> Gerhard Postpischil
> Bradford, VT
>
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Pascal Debug information (was : VS LOADER)

Hercules390 - Mvs mailing list
On 4/14/2017 3:42 AM, Bernd Oppolzer [hidden email] [H390-MVS]
wrote:

> I appreciate that and will check them out soon.
>
> I forgot to mention that PASSNAP is written in Pascal completely;
> it does all the save area checking etc. using only Pascal and it uses
> Pascal I/O (which is based on QSAM) to read the DBGINFO files
> and print the results.
There is one other possibility that would allow you to continue to use
QSAM to read the file, and that is to change OPEN for the debug file:

1) Add two EXLST parameters to the OPEN:
  DC 0A(0),X'05',AL3(XLSTRTIN),X'07',AL3(JFCBDSNM),X'91',AL3(ABNDEXIT)

2) prior to the OPEN, do a RDJFCB dcb  -  define the output area with
IEFJFCBN (140 bytes)

3) move the 8-byte (blank filled) member name to JFCBELNM, and turn on
flag JFCPDS in byte JFCBIND1, also set JFCBTSDM flag JFCVSL on (redrives
allocation and may not be necessary).

4) OPEN with TYPE=J - if the member does not exist, the DCB ABEND exit
will be driven. IIRC, member not found is a recoverable condition (you
can set flags in the exit, then CLOSE after the OPEN). If the member
exists, you can do normal QSAM reads from the DCB.

Also I noticed that you have BFTEK=A in the DCB. In early systems
(OS/360) this caused OPEN to fail unless the RECFM was VS or VBS. You
already have an OPEN exit, so the flag may be set there as needed. I'm
not sure which system release that was fixed in.

Also the code sets a minimum LRECL of 4; some early systems failed on
that, and required 5.  Also early (reel) tape had a minimum of 18 for
the block size.

For output files the OPEN exit should check whether the block size is
legal. For DASD TRKCALC should be used (requires UCB address; that's in
the TIOT entry TIOEFSRT). Better an error message than an abend?

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

Reply | Threaded
Open this post in threaded view
|

Re: Pascal Debug information (was : VS LOADER)

Hercules390 - Mvs mailing list
Thank you again for your valuable support.

I found out that Pascal/VS had functions PDSIN (file, string);
and PDSOUT (file, string);
that opened a PDS member for input or output.
string is a char string with options ???

The details are described in the "Pascal/VS programmer's guide",
which I don't have, unfortunately. It is not available from
bitsavers.org, too. Maybe someone out there has a copy?
(The "Pascal/VS language reference" is mirrored on my web site).

But let's assume that the string contains a member name;
that would be the interface to start with.

I have to confess that I don't understand all your suggestions below;
I only did minor changes to the OPEN EXIT (which I inherited from the
original authors) to set some LRECL and BLKSIZE defaults on CMS which
made more sense than the original values and which allowed less
specifications on FILEDEF. There was much trial and error involved.

Anyway: I will try to incorporate all of your suggestions into
PASMONN, to maybe get some sort of PDSIN / PDSOUT function
in the end, which will be available to all Pascal programs, not only
to PASSNAP.

Thanks again,
have a nice day

Bernd



Am 14.04.2017 um 10:46 schrieb Gerhard Postpischil [hidden email]
[H390-MVS]:

>
> On 4/14/2017 3:42 AM, Bernd Oppolzer [hidden email] [H390-MVS]
> wrote:
>
> > I appreciate that and will check them out soon.
> >
> > I forgot to mention that PASSNAP is written in Pascal completely;
> > it does all the save area checking etc. using only Pascal and it uses
> > Pascal I/O (which is based on QSAM) to read the DBGINFO files
> > and print the results.
> There is one other possibility that would allow you to continue to use
> QSAM to read the file, and that is to change OPEN for the debug file:
>
> 1) Add two EXLST parameters to the OPEN:
> DC 0A(0),X'05',AL3(XLSTRTIN),X'07',AL3(JFCBDSNM),X'91',AL3(ABNDEXIT)
>
> 2) prior to the OPEN, do a RDJFCB dcb - define the output area with
> IEFJFCBN (140 bytes)
>
> 3) move the 8-byte (blank filled) member name to JFCBELNM, and turn on
> flag JFCPDS in byte JFCBIND1, also set JFCBTSDM flag JFCVSL on (redrives
> allocation and may not be necessary).
>
> 4) OPEN with TYPE=J - if the member does not exist, the DCB ABEND exit
> will be driven. IIRC, member not found is a recoverable condition (you
> can set flags in the exit, then CLOSE after the OPEN). If the member
> exists, you can do normal QSAM reads from the DCB.
>
> Also I noticed that you have BFTEK=A in the DCB. In early systems
> (OS/360) this caused OPEN to fail unless the RECFM was VS or VBS. You
> already have an OPEN exit, so the flag may be set there as needed. I'm
> not sure which system release that was fixed in.
>
> Also the code sets a minimum LRECL of 4; some early systems failed on
> that, and required 5. Also early (reel) tape had a minimum of 18 for
> the block size.
>
> For output files the OPEN exit should check whether the block size is
> legal. For DASD TRKCALC should be used (requires UCB address; that's in
> the TIOT entry TIOEFSRT). Better an error message than an abend?
>
> Gerhard Postpischil
> Bradford, VT
>

Reply | Threaded
Open this post in threaded view
|

Re: VS LOADER

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
On 14 April 2017 at 01:11, Jon Perryman [hidden email] wrote:

> I was referring to the HLASM and IBM C GOFF option. I used it in
> conjunction with XDC so I'm not sure about the implementation specifics but
> in team environments separate debug files were a nuisance. Better would
> have been if XDC could have used it from a separate load module in the same
> library but at least it was easy to keep things in sync when dealing with
> others.


So where *does* the debug info live in this scheme?

Tony H.
Reply | Threaded
Open this post in threaded view
|

Re: Pascal Debug information (was : VS LOADER)

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
With the help of Gerhard, I was able to add "member support"
to the Stanford Pascal runtime.

There is a new function ASSIGNMEM, which can be applied to a Pascal file
before open and which assigns a member name to the file. The member name
is stored in the Pascal FCB. For files, that are not assigned to PO
datasets,
the member name is ignored. But for PO datasets, the member from the
Pascal FCB is located on OPEN (if there is no member on the DD statement
- if there
is a member on the DD statement, that member is overridden).

Later: if there is no member in the FCB and no member on the DD statement,
the directory of the PO dataset will be read.

See the following example - a program which reads two members of a PO
dataset
in the same program run:

program TESTPDS ( INPUT , OUTPUT , PDS ) ;

type CHAR8 = array [ 1 .. 8 ] of CHAR ;
      CHAR80 = array [ 1 .. 80 ] of CHAR ;

var PDS : TEXT ;
     MEMBERNAME : CHAR8 ;
     ZEILE : CHAR80 ;

procedure TESTREAD ;

    begin (* TESTREAD *)
      RESET ( PDS ) ;
      repeat
        READLN ( PDS , ZEILE ) ;
        WRITELN ( ' ' , ZEILE )
      until EOF ( PDS ) ;
      CLOSE ( PDS ) ;
    end (* TESTREAD *) ;

begin (* HAUPTPROGRAMM *)
   MEMBERNAME := 'RUNKAL' ;
   WRITELN ( ' ' , 'vor assignmem' ) ;
   ASSIGNMEM ( PDS , ADDR ( MEMBERNAME ) , 8 ) ;
   WRITELN ( ' ' , 'nach assignmem' ) ;
   TESTREAD ;
   MEMBERNAME := 'RUNFIB' ;
   WRITELN ( ' ' , 'vor assignmem' ) ;
   ASSIGNMEM ( PDS , ADDR ( MEMBERNAME ) , 8 ) ;
   WRITELN ( ' ' , 'nach assignmem' ) ;
   TESTREAD ;
end (* HAUPTPROGRAMM *) .

Job Control for Compile, Link and Go:

//PASCALNT JOB (PASCAL),'TEST TESTPDS',CLASS=A,MSGCLASS=X,
//             TIME=1440,REGION=8000K,MSGLEVEL=(1,1)
//COMPGO   EXEC PASNCLG,MEM=TESTPDS,
//         SRC='PASCALN.TESTPGM.PAS',
//         MOD='PASCALN.TESTPGM.LOAD'
//LKED.SYSIN DD *
   INCLUDE SYSLIB(PASUTILS)
//GO.PDS   DD  DISP=SHR,DSN=PASCALN.TESTPGM.CNTL(X)
//*GO.PDS   DD  DISP=SHR,DSN=PASCALN.TESTPGM.CNTL  --- is ok, too

works without problems.

Thanks again to Gerhard for his valuable support.

Kind regards,
have a nice Sunday.

Bernd



Am 14.04.2017 um 11:21 schrieb Bernd Oppolzer [hidden email]
[H390-MVS]:

>
> Thank you again for your valuable support.
>
> I found out that Pascal/VS had functions PDSIN (file, string);
> and PDSOUT (file, string);
> that opened a PDS member for input or output.
> string is a char string with options ???
>
> The details are described in the "Pascal/VS programmer's guide",
> which I don't have, unfortunately. It is not available from
> bitsavers.org, too. Maybe someone out there has a copy?
> (The "Pascal/VS language reference" is mirrored on my web site).
>
> But let's assume that the string contains a member name;
> that would be the interface to start with.
>
> I have to confess that I don't understand all your suggestions below;
> I only did minor changes to the OPEN EXIT (which I inherited from the
> original authors) to set some LRECL and BLKSIZE defaults on CMS which
> made more sense than the original values and which allowed less
> specifications on FILEDEF. There was much trial and error involved.
>
> Anyway: I will try to incorporate all of your suggestions into
> PASMONN, to maybe get some sort of PDSIN / PDSOUT function
> in the end, which will be available to all Pascal programs, not only
> to PASSNAP.
>
> Thanks again,
> have a nice day
>
> Bernd
>
>
>
> Am 14.04.2017 um 10:46 schrieb Gerhard Postpischil
> [hidden email] [H390-MVS]:
>>
>> On 4/14/2017 3:42 AM, Bernd Oppolzer [hidden email] [H390-MVS]
>> wrote:
>>
>> > I appreciate that and will check them out soon.
>> >
>> > I forgot to mention that PASSNAP is written in Pascal completely;
>> > it does all the save area checking etc. using only Pascal and it uses
>> > Pascal I/O (which is based on QSAM) to read the DBGINFO files
>> > and print the results.
>> There is one other possibility that would allow you to continue to use
>> QSAM to read the file, and that is to change OPEN for the debug file:
>>
>> 1) Add two EXLST parameters to the OPEN:
>> DC 0A(0),X'05',AL3(XLSTRTIN),X'07',AL3(JFCBDSNM),X'91',AL3(ABNDEXIT)
>>
>> 2) prior to the OPEN, do a RDJFCB dcb - define the output area with
>> IEFJFCBN (140 bytes)
>>
>> 3) move the 8-byte (blank filled) member name to JFCBELNM, and turn on
>> flag JFCPDS in byte JFCBIND1, also set JFCBTSDM flag JFCVSL on (redrives
>> allocation and may not be necessary).
>>
>> 4) OPEN with TYPE=J - if the member does not exist, the DCB ABEND exit
>> will be driven. IIRC, member not found is a recoverable condition (you
>> can set flags in the exit, then CLOSE after the OPEN). If the member
>> exists, you can do normal QSAM reads from the DCB.
>>
>> Also I noticed that you have BFTEK=A in the DCB. In early systems
>> (OS/360) this caused OPEN to fail unless the RECFM was VS or VBS. You
>> already have an OPEN exit, so the flag may be set there as needed. I'm
>> not sure which system release that was fixed in.
>>
>> Also the code sets a minimum LRECL of 4; some early systems failed on
>> that, and required 5. Also early (reel) tape had a minimum of 18 for
>> the block size.
>>
>> For output files the OPEN exit should check whether the block size is
>> legal. For DASD TRKCALC should be used (requires UCB address; that's in
>> the TIOT entry TIOEFSRT). Better an error message than an abend?
>>
>> Gerhard Postpischil
>> Bradford, VT
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: VS LOADER

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
Assembler GOFF allows you to put the ADATA to SYSLIN or SYSPUNCH. For my situation, SYSLIN was more convenient because I could just send a module to QA. It meant I knew the XDC display was the correct information. The drawback was a much larger load module but was seldom a problem because it was for internal use.
Jon.

    On Friday, April 14, 2017 8:54 PM, "Tony Harminc [hidden email] [H390-MVS]" <[hidden email]> wrote:
 

    
On 14 April 2017 at 01:11, Jon Perryman [hidden email] wrote:

I was referring to the HLASM and IBM C GOFF option. I used it in conjunction with XDC so I'm not sure about the implementation specifics but in team environments separate debug files were a nuisance. Better would have been if XDC could have used it from a separate load module in the same library but at least it was easy to keep things in sync when dealing with others.

So where *does* the debug info live in this scheme?

Tony H.
  #yiv6645670708 #yiv6645670708 -- #yiv6645670708ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv6645670708 #yiv6645670708ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv6645670708 #yiv6645670708ygrp-mkp #yiv6645670708hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv6645670708 #yiv6645670708ygrp-mkp #yiv6645670708ads {margin-bottom:10px;}#yiv6645670708 #yiv6645670708ygrp-mkp .yiv6645670708ad {padding:0 0;}#yiv6645670708 #yiv6645670708ygrp-mkp .yiv6645670708ad p {margin:0;}#yiv6645670708 #yiv6645670708ygrp-mkp .yiv6645670708ad a {color:#0000ff;text-decoration:none;}#yiv6645670708 #yiv6645670708ygrp-sponsor #yiv6645670708ygrp-lc {font-family:Arial;}#yiv6645670708 #yiv6645670708ygrp-sponsor #yiv6645670708ygrp-lc #yiv6645670708hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv6645670708 #yiv6645670708ygrp-sponsor #yiv6645670708ygrp-lc .yiv6645670708ad {margin-bottom:10px;padding:0 0;}#yiv6645670708 #yiv6645670708actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv6645670708 #yiv6645670708activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv6645670708 #yiv6645670708activity span {font-weight:700;}#yiv6645670708 #yiv6645670708activity span:first-child {text-transform:uppercase;}#yiv6645670708 #yiv6645670708activity span a {color:#5085b6;text-decoration:none;}#yiv6645670708 #yiv6645670708activity span span {color:#ff7900;}#yiv6645670708 #yiv6645670708activity span .yiv6645670708underline {text-decoration:underline;}#yiv6645670708 .yiv6645670708attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv6645670708 .yiv6645670708attach div a {text-decoration:none;}#yiv6645670708 .yiv6645670708attach img {border:none;padding-right:5px;}#yiv6645670708 .yiv6645670708attach label {display:block;margin-bottom:5px;}#yiv6645670708 .yiv6645670708attach label a {text-decoration:none;}#yiv6645670708 blockquote {margin:0 0 0 4px;}#yiv6645670708 .yiv6645670708bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv6645670708 .yiv6645670708bold a {text-decoration:none;}#yiv6645670708 dd.yiv6645670708last p a {font-family:Verdana;font-weight:700;}#yiv6645670708 dd.yiv6645670708last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv6645670708 dd.yiv6645670708last p span.yiv6645670708yshortcuts {margin-right:0;}#yiv6645670708 div.yiv6645670708attach-table div div a {text-decoration:none;}#yiv6645670708 div.yiv6645670708attach-table {width:400px;}#yiv6645670708 div.yiv6645670708file-title a, #yiv6645670708 div.yiv6645670708file-title a:active, #yiv6645670708 div.yiv6645670708file-title a:hover, #yiv6645670708 div.yiv6645670708file-title a:visited {text-decoration:none;}#yiv6645670708 div.yiv6645670708photo-title a, #yiv6645670708 div.yiv6645670708photo-title a:active, #yiv6645670708 div.yiv6645670708photo-title a:hover, #yiv6645670708 div.yiv6645670708photo-title a:visited {text-decoration:none;}#yiv6645670708 div#yiv6645670708ygrp-mlmsg #yiv6645670708ygrp-msg p a span.yiv6645670708yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv6645670708 .yiv6645670708green {color:#628c2a;}#yiv6645670708 .yiv6645670708MsoNormal {margin:0 0 0 0;}#yiv6645670708 o {font-size:0;}#yiv6645670708 #yiv6645670708photos div {float:left;width:72px;}#yiv6645670708 #yiv6645670708photos div div {border:1px solid #666666;height:62px;overflow:hidden;width:62px;}#yiv6645670708 #yiv6645670708photos div label {color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv6645670708 #yiv6645670708reco-category {font-size:77%;}#yiv6645670708 #yiv6645670708reco-desc {font-size:77%;}#yiv6645670708 .yiv6645670708replbq {margin:4px;}#yiv6645670708 #yiv6645670708ygrp-actbar div a:first-child {margin-right:2px;padding-right:5px;}#yiv6645670708 #yiv6645670708ygrp-mlmsg {font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv6645670708 #yiv6645670708ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv6645670708 #yiv6645670708ygrp-mlmsg select, #yiv6645670708 input, #yiv6645670708 textarea {font:99% Arial, Helvetica, clean, sans-serif;}#yiv6645670708 #yiv6645670708ygrp-mlmsg pre, #yiv6645670708 code {font:115% monospace;}#yiv6645670708 #yiv6645670708ygrp-mlmsg * {line-height:1.22em;}#yiv6645670708 #yiv6645670708ygrp-mlmsg #yiv6645670708logo {padding-bottom:10px;}#yiv6645670708 #yiv6645670708ygrp-msg p a {font-family:Verdana;}#yiv6645670708 #yiv6645670708ygrp-msg p#yiv6645670708attach-count span {color:#1E66AE;font-weight:700;}#yiv6645670708 #yiv6645670708ygrp-reco #yiv6645670708reco-head {color:#ff7900;font-weight:700;}#yiv6645670708 #yiv6645670708ygrp-reco {margin-bottom:20px;padding:0px;}#yiv6645670708 #yiv6645670708ygrp-sponsor #yiv6645670708ov li a {font-size:130%;text-decoration:none;}#yiv6645670708 #yiv6645670708ygrp-sponsor #yiv6645670708ov li {font-size:77%;list-style-type:square;padding:6px 0;}#yiv6645670708 #yiv6645670708ygrp-sponsor #yiv6645670708ov ul {margin:0;padding:0 0 0 8px;}#yiv6645670708 #yiv6645670708ygrp-text {font-family:Georgia;}#yiv6645670708 #yiv6645670708ygrp-text p {margin:0 0 1em 0;}#yiv6645670708 #yiv6645670708ygrp-text tt {font-size:120%;}#yiv6645670708 #yiv6645670708ygrp-vital ul li:last-child {border-right:none !important;}#yiv6645670708