f



Enterprise pl1 V3R8 to V4R1 migration issue (zOS)

Hi there,

I am currently facing an issue in the migration from V3R8 to V4R1.
Here is a small example program, which is correctly compiling under V3R8:

TEST03: PROCEDURE(PARMS) OPTIONS(MAIN);                           
                                                                  
  DCL    PARMS           CHAR(255) VARYING;                       
  DCL    CEEGTST         ENTRY(BIN FIXED(31),BIN FIXED(31),POINTER
                              ,CHAR(12)) OPTIONS(ASM);            
  DCL    FC              CHAR(12);                                
  DCL    DEPTH           BIN FIXED(31);                           
  DCL    WIDTH           BIN FIXED(31);                           
  DCL    SCREEN_PR       POINTER;                                 
  DCL 01 SCREEN(DEPTH)   BASED(SCREEN_PR) UNALIGNED,              
         05 DATA         CHAR(WIDTH);                
                                                                  
  CALL CEEGTST(0,DEPTH * WIDTH,SCREEN_PR,FC);                     
                                                                  
  SCREEN(*) = '';                                                 
                                                                  
  DISPLAY(SIZE(SCREEN));                                          
                                                                  
END TEST03;                                                       

The same program is giving the following compile error under V4R1:

IBM2209I S      10.0    Use of nonconstant extents in BASED variables without
                        REFER is invalid except on scalars.                  

I tried this modification:

  DCL    DUMMY           BIN FIXED(31);                           
  DCL 01 SCREEN(DUMMY REFER(DEPTH))   BASED(SCREEN_PR) UNALIGNED,              
         05 DATA         CHAR(WIDTH);                

Leading to this error:

IBM1893I S      11.0    REFER is allowed only on members of structures and
                        unions.                                           

Then I tried this:

DCL 01 SCREEN          BASED(SCREEN_PR) UNALIGNED,
       05 DATA(DUMMY REFER(DEPTH))  CHAR(WIDTH);  

Leading to:

IBM1887I S      12.0    The REFER object DEPTH must be an element of the same
                        structure where it is used, and must precede its     
                        first usage in that structure.                       

I am a bit stuck as, in this case, the REFER object DEPTH is not (and can not be) part of the structure where it is used.
Any idea how I can adapt this program to make it compatible with the latest versions of the compiler ?

Note that this example program is just to demonstrate the problem.
In the real program, DEPTH and WIDTH are unkown at compile time.
And the SCREEN structure must be BASED (not AUTOMATIC, nor CONTROLLED).
I'm using CEEGTST to do the allocation instead of a simple ALLOCATE statement because it needs to be allocated out of the default heap.

Thanks,
Renaud.



0
renaud
10/10/2013 8:14:44 AM
comp.lang.pl1 1741 articles. 0 followers. Post Follow

118 Replies
1017 Views

Similar Articles

[PageSpeed] 44

On Thursday, October 10, 2013 7:14:44 PM UTC+11, renau...@gmail.com wrote:
> Hi there, I am currently facing an issue in the migration from V3R8 to V4=
R1. Here is a small example program, which is correctly compiling under V3R=
8:
> TEST03: PROCEDURE(PARMS) OPTIONS(MAIN); DCL PARMS CHAR(255) VARYING; DCL =
CEEGTST ENTRY(BIN FIXED(31),BIN FIXED(31),POINTER ,CHAR(12)) OPTIONS(ASM); =
DCL FC CHAR(12); DCL DEPTH BIN FIXED(31); DCL WIDTH BIN FIXED(31); DCL SCRE=
EN_PR POINTER; DCL 01 SCREEN(DEPTH) BASED(SCREEN_PR) UNALIGNED, 05 DATA CHA=
R(WIDTH);
> CALL CEEGTST(0,DEPTH * WIDTH,SCREEN_PR,FC);
> SCREEN(*) =3D '';

How can this assignment work? (did I miss something?)

The extent of array "screen" is not known.
0
robin
10/10/2013 11:31:55 AM
On Thursday, October 10, 2013 7:14:44 PM UTC+11, renau...@gmail.com wrote:
> Hi there, I am currently facing an issue in the migration from V3R8 to V4R1. Here is a small example program, which is correctly compiling under V3R8:

> TEST03: PROCEDURE(PARMS) OPTIONS(MAIN);

Have you checked compiler options?  Is there a relevant LAXxx option?
0
robin
10/10/2013 11:58:18 AM
On 10/10/2013 7:31 AM, robin.vowels@gmail.com wrote:
> On Thursday, October 10, 2013 7:14:44 PM UTC+11, renau...@gmail.com wrote:
>> Hi there, I am currently facing an issue in the migration from V3R8 to V4R1. Here is a small example program, which is correctly compiling under V3R8:
>> TEST03: PROCEDURE(PARMS) OPTIONS(MAIN); DCL PARMS CHAR(255) VARYING; DCL CEEGTST ENTRY(BIN FIXED(31),BIN FIXED(31),POINTER ,CHAR(12)) OPTIONS(ASM); DCL FC CHAR(12); DCL DEPTH BIN FIXED(31); DCL WIDTH BIN FIXED(31); DCL SCREEN_PR POINTER; DCL 01 SCREEN(DEPTH) BASED(SCREEN_PR) UNALIGNED, 05 DATA CHAR(WIDTH);
>> CALL CEEGTST(0,DEPTH * WIDTH,SCREEN_PR,FC);
>> SCREEN(*) = '';
>
> How can this assignment work? (did I miss something?)
>
> The extent of array "screen" is not known.
>

This never should have worked.

I would suggest something like:

DCL SCREEN CHAR(32760) BASED(SCREEN_PR);

Since this is only an overlay you're nor reserving storage.  Then 
compute the position of the data from WIDTH and DEPTH and use 
SUBSTR(SCREEN,POS,LEN) to reference it, or use PLIMOVE and friends.
If STRINGRANGE is not enabled the actual size defined for SCREEN doesn't 
matter.

I don't recommend this type of coding normally, but it /does/ solve the 
problem.

-- 
Pete
0
Peter
10/10/2013 12:00:36 PM
Le jeudi 10 octobre 2013 13:31:55 UTC+2, robin....@gmail.com a =E9crit=A0:
> On Thursday, October 10, 2013 7:14:44 PM UTC+11, renau...@gmail.com wrote=
:
>=20
> > Hi there, I am currently facing an issue in the migration from V3R8 to =
V4R1. Here is a small example program, which is correctly compiling under V=
3R8:
>=20
> > TEST03: PROCEDURE(PARMS) OPTIONS(MAIN); DCL PARMS CHAR(255) VARYING; DC=
L CEEGTST ENTRY(BIN FIXED(31),BIN FIXED(31),POINTER ,CHAR(12)) OPTIONS(ASM)=
; DCL FC CHAR(12); DCL DEPTH BIN FIXED(31); DCL WIDTH BIN FIXED(31); DCL SC=
REEN_PR POINTER; DCL 01 SCREEN(DEPTH) BASED(SCREEN_PR) UNALIGNED, 05 DATA C=
HAR(WIDTH);
>=20
> > CALL CEEGTST(0,DEPTH * WIDTH,SCREEN_PR,FC);
>=20
> > SCREEN(*) =3D '';
>=20
>=20
>=20
> How can this assignment work? (did I miss something?)
>=20
>=20
>=20
> The extent of array "screen" is not known.

Ok, sorry, assume WIDHT and DEPTH variables are correctly initialised befor=
e the call to CEEGTST.  I missed it when copying the relevant bits from the=
 original program.
0
renaud
10/10/2013 1:08:58 PM
Le jeudi 10 octobre 2013 14:00:36 UTC+2, Peter Flass a =E9crit=A0:
> On 10/10/2013 7:31 AM, robin.vowels@gmail.com wrote:
>=20
> > On Thursday, October 10, 2013 7:14:44 PM UTC+11, renau...@gmail.com wro=
te:
>=20
> >> Hi there, I am currently facing an issue in the migration from V3R8 to=
 V4R1. Here is a small example program, which is correctly compiling under =
V3R8:
>=20
> >> TEST03: PROCEDURE(PARMS) OPTIONS(MAIN); DCL PARMS CHAR(255) VARYING; D=
CL CEEGTST ENTRY(BIN FIXED(31),BIN FIXED(31),POINTER ,CHAR(12)) OPTIONS(ASM=
); DCL FC CHAR(12); DCL DEPTH BIN FIXED(31); DCL WIDTH BIN FIXED(31); DCL S=
CREEN_PR POINTER; DCL 01 SCREEN(DEPTH) BASED(SCREEN_PR) UNALIGNED, 05 DATA =
CHAR(WIDTH);
>=20
> >> CALL CEEGTST(0,DEPTH * WIDTH,SCREEN_PR,FC);
>=20
> >> SCREEN(*) =3D '';
>=20
> >
>=20
> > How can this assignment work? (did I miss something?)
>=20
> >
>=20
> > The extent of array "screen" is not known.
>=20
> >
>=20
>=20
>=20
> This never should have worked.
>=20
>=20
>=20
> I would suggest something like:
>=20
>=20
>=20
> DCL SCREEN CHAR(32760) BASED(SCREEN_PR);
>=20
>=20
>=20
> Since this is only an overlay you're nor reserving storage.  Then=20
>=20
> compute the position of the data from WIDTH and DEPTH and use=20
>=20
> SUBSTR(SCREEN,POS,LEN) to reference it, or use PLIMOVE and friends.
>=20
> If STRINGRANGE is not enabled the actual size defined for SCREEN doesn't=
=20
>=20
> matter.
>=20
>=20
>=20
> I don't recommend this type of coding normally, but it /does/ solve the=
=20
>=20
> problem.
>=20
>=20
>=20
> --=20
>=20
> Pete

Hi Peter,

While you solution is technically valid, it's totally inelegant and adding =
complexity in my code.
For the sake of simplicity of the example, I defined each line of the scree=
n array as a simple character string.  In reality, each line is a structure=
 made of different fields, with the last field being CHAR(WIDTH-sum of the =
length of the previous fields).
0
renaud
10/10/2013 1:13:31 PM
Le jeudi 10 octobre 2013 13:58:18 UTC+2, robin....@gmail.com a =E9crit=A0:
> On Thursday, October 10, 2013 7:14:44 PM UTC+11, renau...@gmail.com wrote=
:
>=20
> > Hi there, I am currently facing an issue in the migration from V3R8 to =
V4R1. Here is a small example program, which is correctly compiling under V=
3R8:
>=20
>=20
>=20
> > TEST03: PROCEDURE(PARMS) OPTIONS(MAIN);
>=20
>=20
>=20
> Have you checked compiler options?  Is there a relevant LAXxx option?

Hi Robin,

I just quickly went through all the suboptions of the RULES compiler option=
..
I don't see any that would change the compiler behavior in this case.

Here are the options I am using (with both versions of the compiler):

OPTIMIZE(0),PREFIX(SUBSCRIPTRANGE),TEST(NONE,NONE),GONUMBER,PP(),      =20
AGGREGATE,ATTRIBUTES(FULL),NOINSOURCE,LINECOUNT(60),              =20
CMPAT(LE),ARCH(5),DISPLAY(STD),MAXMEM(2097152),                   =20
XREF(FULL),SOURCE,MARGINS(2,72,1),NEST,OFFSET,OPTIONS,MAP,        =20
STORAGE,SYNTAX,MARGINI(' '),NOLIST,NORENT,FLAG(I),MACRO,          =20
DEFAULT(REORDER,DUMMY(UNALIGNED),CONNECTED,NODESCRIPTOR,NOOVERLAP),
LIMITS(EXTNAME(8),FIXEDDEC(31),FIXEDBIN(31,63)),                  =20
RULES(IBM,NOLAXBIF,NOLAXCTL,NOLAXDCL,NOLAXIF,NOLAXLINK,           =20
NOLAXPUNC,NOLAXQUAL,NOLAXSTRZ,NOMULTICLOSE)                     =20

0
renaud
10/10/2013 1:31:08 PM
On 2013-10-10 11:31:55 +0000, robin.vowels@gmail.com said:

> On Thursday, October 10, 2013 7:14:44 PM UTC+11, renau...@gmail.com wrote:
>> Hi there, I am currently facing an issue in the migration from V3R8 to 
>> V4R1. Here is a small example program, which is correctly compiling 
>> under V3R8:
>> TEST03: PROCEDURE(PARMS) OPTIONS(MAIN); DCL PARMS CHAR(255) VARYING; 
>> DCL CEEGTST ENTRY(BIN FIXED(31),BIN FIXED(31),POINTER ,CHAR(12)) 
>> OPTIONS(ASM); DCL FC CHAR(12); DCL DEPTH BIN FIXED(31); DCL WIDTH BIN 
>> FIXED(31); DCL SCREEN_PR POINTER; DCL 01 SCREEN(DEPTH) BASED(SCREEN_PR) 
>> UNALIGNED, 05 DATA CHAR(WIDTH);
>> CALL CEEGTST(0,DEPTH * WIDTH,SCREEN_PR,FC);
>> SCREEN(*) = '';
> 
> How can this assignment work? (did I miss something?)
> 
> The extent of array "screen" is not known.

I agree. V4R1 has some relaxation of the REFER requirement, compared to 
historic versions, but it doesn't allow two-dimensional cases. As far 
as I can tell, this code should never have compiled at all. See 
http://publibfp.dhe.ibm.com/cgi-bin/bookmgr/BOOKS/c1472851/10.5.1?SHELF=&DT=20110908013800&CASE= 


-- 
John W Kennedy
A proud member of the reality-based community.

0
John
10/10/2013 2:34:09 PM
On Friday, October 11, 2013 1:34:09 AM UTC+11, John W Kennedy wrote:
> On 2013-10-10 11:31:55 +0000, rob....@gmail.com said: > On Thursday, Octo=
ber 10, 2013 7:14:44 PM UTC+11, renau...@gmail.com wrote: >> Hi there, I am=
 currently facing an issue in the migration from V3R8 to >> V4R1. Here is a=
 small example program, which is correctly compiling >> under V3R8: >> TEST=
03: PROCEDURE(PARMS) OPTIONS(MAIN); DCL PARMS CHAR(255) VARYING; >> DCL CEE=
GTST ENTRY(BIN FIXED(31),BIN FIXED(31),POINTER ,CHAR(12)) >> OPTIONS(ASM); =
DCL FC CHAR(12); DCL DEPTH BIN FIXED(31); DCL WIDTH BIN >> FIXED(31); DCL S=
CREEN_PR POINTER; DCL 01 SCREEN(DEPTH) BASED(SCREEN_PR) >> UNALIGNED, 05 DA=
TA CHAR(WIDTH); >> CALL CEEGTST(0,DEPTH * WIDTH,SCREEN_PR,FC); >> SCREEN(*)=
 =3D ''; > > How can this assignment work? (did I miss something?) > > The =
extent of array "screen" is not known. I agree. V4R1 has some relaxation of=
 the REFER requirement, compared to historic versions, but it doesn't allow=
 two-dimensional cases. As far as I can tell, this code should never have c=
ompiled at all.
> See http://publibfp.dhe.ibm.com/cgi-bin/bookmgr/BOOKS/c1472851/10.5.1?SHE=
LF=3D&DT=3D20110908013800&CASE=3D

Example 5 is essentially the same as the OP's case.
It has an array of size n and a string of length m.
0
robin
10/10/2013 10:36:57 PM
On Thursday, October 10, 2013 7:14:44 PM UTC+11, renau...@gmail.com wrote:
> Hi there, I am currently facing an issue in the migration from V3R8 to V4=
R1. Here is a small example program, which is correctly compiling under V3R=
8:
> TEST03: PROCEDURE(PARMS) OPTIONS(MAIN); DCL PARMS CHAR(255) VARYING; DCL =
CEEGTST ENTRY(BIN FIXED(31),BIN FIXED(31),POINTER ,CHAR(12)) OPTIONS(ASM); =
DCL FC CHAR(12); DCL DEPTH BIN FIXED(31); DCL WIDTH BIN FIXED(31); DCL SCRE=
EN_PR POINTER; DCL 01 SCREEN(DEPTH) BASED(SCREEN_PR) UNALIGNED, 05 DATA CHA=
R(WIDTH); CALL CEEGTST(0,DEPTH * WIDTH,SCREEN_PR,FC); SCREEN(*) =3D ''; DIS=
PLAY(SIZE(SCREEN));
> END TEST03;

What about changing the declaration to:

DECLARE 1 SCREEN BASED(SCREEN_PR),
           2 X(Depth) CHAR (Width);
0
robin
10/10/2013 10:46:15 PM
On 2013-10-10 22:36:57 +0000, robin.vowels@gmail.com said:

> On Friday, October 11, 2013 1:34:09 AM UTC+11, John W Kennedy wrote:
>> On 2013-10-10 11:31:55 +0000, rob....@gmail.com said: > On Thursday, 
>> October 10, 2013 7:14:44 PM UTC+11, renau...@gmail.com wrote: >> Hi 
>> there, I am currently facing an issue in the migration from V3R8 to >> 
>> V4R1. Here is a small example program, which is correctly compiling >> 
>> under V3R8: >> TEST03: PROCEDURE(PARMS) OPTIONS(MAIN); DCL PARMS 
>> CHAR(255) VARYING; >> DCL CEEGTST ENTRY(BIN FIXED(31),BIN 
>> FIXED(31),POINTER ,CHAR(12)) >> OPTIONS(ASM); DCL FC CHAR(12); DCL 
>> DEPTH BIN FIXED(31); DCL WIDTH BIN >> FIXED(31); DCL SCREEN_PR POINTER; 
>> DCL 01 SCREEN(DEPTH) BASED(SCREEN_PR) >> UNALIGNED, 05 DATA 
>> CHAR(WIDTH); >> CALL CEEGTST(0,DEPTH * WIDTH,SCREEN_PR,FC); >> 
>> SCREEN(*) = ''; > > How can this assignment work? (did I miss 
>> something?) > > The extent of array "screen" is not known. I agree. 
>> V4R1 has some relaxation of the REFER requirement, compared to historic 
>> versions, but it doesn't allow two-dimensional cases. As far as I can 
>> tell, this code should never have compiled at all.
>> See 
>> http://publibfp.dhe.ibm.com/cgi-bin/bookmgr/BOOKS/c1472851/10.5.1?SHELF=&DT=20110908013800&CASE 
>> 
> Example 5 is essentially the same as the OP's case.
> It has an array of size n and a string of length m.

You're right the example, but I suspect the example is wrong. On purely 
theoretical grounds, it presents the same problems in generating object 
code that a 2-dimensional adjustable array would; if the compiler could 
solve this, it should be able to solve all the other problems with 
roughly the same effort.

I really think it's APAR time (or whatever they're calling them today). 
The compiler may be wrong, the manual may be wrong, or both may be 
wrong, but the whole thing just seems fishy to me.

-- 
John W Kennedy
"Though a Rothschild you may be
In your own capacity,
    As a Company you've come to utter sorrow--
But the Liquidators say,
'Never mind--you needn't pay,'
    So you start another company to-morrow!"
  -- Sir William S. Gilbert.  "Utopia Limited"

0
John
10/11/2013 3:22:03 AM
John W Kennedy wrote:

....
>
> You're right the example, but I suspect the example is wrong. On purely theoretical grounds, it presents the same
> problems in generating object code that a 2-dimensional adjustable array would; if the compiler could solve this, it
> should be able to solve all the other problems with roughly the same effort.
>
> I really think it's APAR time (or whatever they're calling them today). The compiler may be wrong, the manual may be
> wrong, or both may be wrong, but the whole thing just seems fishy to me.
>
Am I missing something? Isn't the compiler simply generating anonymous refer variables at the start of the structure?
0
James
10/11/2013 4:56:58 AM
> 
> What about changing the declaration to:
> 
> 
> 
> DECLARE 1 SCREEN BASED(SCREEN_PR),
> 
>            2 X(Depth) CHAR (Width);


Hi Robin,

This declaration is accepted by the compiler (V4R1).
There is some fuzzy in the doc in this area.
While this is matching the fifth example given at  http://publibfp.dhe.ibm.com/cgi-bin/bookmgr/BOOKS/c1472851/10.5.1?SHELF=&DT=20110908013800&CASE= , this seems to be in contradiction with the description given.

Anyway, unfortunately I over simplified the example program I gave when opening this thread.
The exact declaration causing me the issue is this one:

DCL 01 TDSPD(CDEPTH)          UNALIGNED BASED(TDSPD_PR),
       05 LIN_TYP_CD          CHAR(1),                  
       05 FST_LNE             TYPE(TLINEID),            
       05 LST_LNE             TYPE(TLINEID),            
       05 REC_UPD_STU_CD      BIT(3),                   
       05 REC_TCT_FL          BIT(1),                   
       05 REC_TYP_CD          BIT(3),                   
       05 *                   BIT(1),                   
       05 RAW_CMD_ID          CHAR(6),                  
       05 ORI_DAT_TX          CHAR(CWIDTH - 8);         

I still don't find any elegant equivalent accepted by the latest version of the compiler.
0
renaud
10/11/2013 6:52:48 AM
> > Example 5 is essentially the same as the OP's case.
> > It has an array of size n and a string of length m.
> 
> You're right the example, but I suspect the example is wrong. On purely 
> theoretical grounds, it presents the same problems in generating object 
> code that a 2-dimensional adjustable array would; if the compiler could 
> solve this, it should be able to solve all the other problems with 
> roughly the same effort.
> 

Hi John,

I do confirm that the compiler (V4R1) accepts the following declaration:

DCL 01 SCREEN          BASED(SCREEN_PR) UNALIGNED,
       05 DATA(DEPTH)  CHAR(WIDTH);               

while

DCL 01 SCREEN(DEPTH)   BASED(SCREEN_PR) UNALIGNED,
       05 DATA         CHAR(WIDTH);               

is not accepted.

But I don't find any solution for this:

DCL 01 TDSPD(CDEPTH)          UNALIGNED BASED(TDSPD_PR),
       05 LIN_TYP_CD          CHAR(1),                  
       05 FST_LNE             TYPE(TLINEID),            
       05 LST_LNE             TYPE(TLINEID),            
       05 REC_UPD_STU_CD      BIT(3),                  
       05 REC_TCT_FL          BIT(1),                  
       05 REC_TYP_CD          BIT(3),                  
       05 *                   BIT(1),                  
       05 RAW_CMD_ID          CHAR(6),                  
       05 ORI_DAT_TX          CHAR(CWIDTH - 8);    

Regards,
Renaud.
0
renaud
10/11/2013 6:57:34 AM
On Friday, October 11, 2013 5:52:48 PM UTC+11, renau...@gmail.com wrote:
> > > What about changing the declaration to:
> > > > DECLARE 1 SCREEN BASED(SCREEN_PR),
> > 2 X(Depth) CHAR (Width);

> Hi Robin, This declaration is accepted by the compiler (V4R1). There is s=
ome fuzzy in the doc in this area. While this is matching the fifth example=
 given at
> http://publibfp.dhe.ibm.com/cgi-bin/bookmgr/BOOKS/c1472851/10.5.1?SHELF=
=3D&DT=3D20110908013800&CASE=3D , this seems to be in contradiction with th=
e description given. Anyway, unfortunately I over simplified the example pr=
ogram I gave when opening this thread. The exact declaration causing me the=
 issue is this one: But I don't find any solution for this:=20

DCL 01 TDSPD(CDEPTH)          UNALIGNED BASED(TDSPD_PR),=20
       05 LIN_TYP_CD          CHAR(1),                  =20
       05 FST_LNE             TYPE(TLINEID),            =20
       05 LST_LNE             TYPE(TLINEID),            =20
       05 REC_UPD_STU_CD      BIT(3),                  =20
       05 REC_TCT_FL          BIT(1),                  =20
       05 REC_TYP_CD          BIT(3),                  =20
       05 *                   BIT(1),                  =20
       05 RAW_CMD_ID          CHAR(6),                  =20
       05 ORI_DAT_TX          CHAR(CWIDTH - 8);    =20

Then why not:

DCL 01 TDSPD                  UNALIGNED BASED(TDSPD_PR),
      03 x(CDEPTH),=20
       05 LIN_TYP_CD          CHAR(1),                  =20
       05 FST_LNE             TYPE(TLINEID),            =20
       05 LST_LNE             TYPE(TLINEID),            =20
       05 REC_UPD_STU_CD      BIT(3),                  =20
       05 REC_TCT_FL          BIT(1),                  =20
       05 REC_TYP_CD          BIT(3),                  =20
       05 *                   BIT(1),                  =20
       05 RAW_CMD_ID          CHAR(6),                  =20
       05 ORI_DAT_TX          CHAR(CWIDTH - 8);
0
robin
10/11/2013 7:04:34 AM
> Then why not:
> 
> DCL 01 TDSPD                  UNALIGNED BASED(TDSPD_PR),
>       03 x(CDEPTH), 
>        05 LIN_TYP_CD          CHAR(1),                   
>        05 FST_LNE             TYPE(TLINEID),             
>        05 LST_LNE             TYPE(TLINEID),             
>        05 REC_UPD_STU_CD      BIT(3),                   
>        05 REC_TCT_FL          BIT(1),                   
>        05 REC_TYP_CD          BIT(3),                   
>        05 *                   BIT(1),                   
>        05 RAW_CMD_ID          CHAR(6),                   
>        05 ORI_DAT_TX          CHAR(CWIDTH - 8);

Not accepted by the compiler.  Generating this error:

IBM2209I S      11.0    Use of nonconstant extents in BASED variables without 
                        REFER is invalid except on scalars.                   
0
renaud
10/11/2013 7:27:11 AM
On Friday, October 11, 2013 6:27:11 PM UTC+11, renau...@gmail.com wrote:
> > Then why not:
> > DCL 01 TDSPD UNALIGNED BASED(TDSPD_PR), 
> 03 x(CDEPTH), 
> 05 LIN_TYP_CD CHAR(1), 
> 05 FST_LNE TYPE(TLINEID),
> 05 LST_LNE TYPE(TLINEID),
> 05 REC_UPD_STU_CD BIT(3),
> 05 REC_TCT_FL BIT(1),
> 05 REC_TYP_CD BIT(3),
> 05 * BIT(1),
> 05 RAW_CMD_ID CHAR(6), 
> 05 ORI_DAT_TX CHAR(CWIDTH - 8);

> Not accepted by the compiler. Generating this error:
> IBM2209I S 11.0 Use of nonconstant extents in BASED variables without
> REFER is invalid except on scalars.

This is beginning to look like a compiler error.

Suggest omitting all the "05" stuff except the last two,
and progressively adding one more each time until error occurs.
0
robin
10/11/2013 1:25:07 PM
> Suggest omitting all the "05" stuff except the last two,
> 
> and progressively adding one more each time until error occurs.

Thanks Robin.
I gave it a try, here is the result.

DCL 01 TDSPD                  UNALIGNED BASED(TDSPD_PR),
      03 x(CDEPTH)            CHAR(CWIDTH);

is accepted by the compiler with the following warning message

IBM2629I W      11.0    No debug symbol information will be generated for 
                        TDSPD.                                           

while

DCL 01 TDSPD                  UNALIGNED BASED(TDSPD_PR),
      03 x(CDEPTH),
       05 ORI_DAT_TX          CHAR(CWIDTH); 

is rejected with the following error message

IBM2209I S      11.0    Use of nonconstant extents in BASED variables without 
                        REFER is invalid except on scalars.                   
0
renaud
10/11/2013 1:59:27 PM
I've sent details to Peter Elderon at IBM, and will post any reply here.
0
robin
10/12/2013 9:18:47 PM
Le samedi 12 octobre 2013 23:18:47 UTC+2, robin....@gmail.com a =E9crit=A0:
> I've sent details to Peter Elderon at IBM, and will post any reply here.

Thanks Robin.
0
renaud
10/14/2013 7:42:12 PM
Hi Renaud,


back in V3, the compiler mistakenly allowed some programs to compile that w=
ere illegal according to the LRM which stated that all extents in BASED var=
iables must be constants ( =3D  restricted expressions) unless the extent w=
as specified via REFER.=20

A customer pointed this out and said the compiler should be enforcing the r=
ules given in the LRM, and we started doing this 3.9=20

However, other customers had been exploiting this feature / bug, and when w=
e started objecting all such BASED variables, they were upset.=20

So, we decided to allow a limited set of such BASED with non-constant exten=
ts to be supported and to document exactly what is allowed (which are the s=
imple cases most of the customers wanted). I have included the text from th=
e 4.2 LRM below=20

If he change the structure to CONTROLLED and used ALLOCATE rather than LE t=
o allocate it, then his code would work fine=20

- Peter=20

text from the LRM:=20

If you do not specify the REFER option, the extent specifications in the BA=
SED=20
declarations must be restricted expressions with the following exceptions:=
=20

> A non-constant array extent in a BASED variable is invalid unless the arr=
ay=20
meets all of the following conditions:=20
=96 It is one dimensional.=20
=96 The lower bound of the array is a constant.=20
=96 When it is a part of a structure, the extents of all other fields in th=
e structure=20
are constant, and no fields follow the array and the parent structures, if =
any,=20
of the array.=20

> A non-constant CHAR extent in a BASED variable is invalid unless the stri=
ng is=20
a scalar or it meets all of the following conditions:=20
=96 It is the last element in a structure.=20
=96 It has no parents that are arrays.=20
=96 It has one of these attributes: UNALIGNED, NONVARYING, or VARZ.=20

> Any of the following non-constant extents in a BASED variable are valid o=
nly if=20
the variable is a scalar:=20
=96 The non-constant AREA extent=20
=96 The non-constant BIT extent=20
=96 The non-constant GRAPHIC extent=20
=96 The non-constant WIDECHAR extent
0
robin
10/14/2013 10:43:12 PM
Hi Renaud,
   Here is Peter Elderon's reply:--


back in V3, the compiler mistakenly allowed some programs to compile that w=
ere illegal according to the LRM which stated that all extents in BASED var=
iables must be constants ( =3D  restricted expressions) unless the extent w=
as specified via REFER.=20

A customer pointed this out and said the compiler should be enforcing the r=
ules given in the LRM, and we started doing this 3.9=20

However, other customers had been exploiting this feature / bug, and when w=
e started objecting all such BASED variables, they were upset.=20

So, we decided to allow a limited set of such BASED with non-constant exten=
ts to be supported and to document exactly what is allowed (which are the s=
imple cases most of the customers wanted). I have included the text from th=
e 4.2 LRM below=20

If he change the structure to CONTROLLED and used ALLOCATE rather than LE t=
o allocate it, then his code would work fine=20

- Peter=20

text from the LRM:=20

If you do not specify the REFER option, the extent specifications in the BA=
SED=20
declarations must be restricted expressions with the following exceptions:=
=20

> A non-constant array extent in a BASED variable is invalid unless the arr=
ay=20
meets all of the following conditions:=20
=96 It is one dimensional.=20
=96 The lower bound of the array is a constant.=20
=96 When it is a part of a structure, the extents of all other fields in th=
e structure=20
are constant, and no fields follow the array and the parent structures, if =
any,=20
of the array.=20

> A non-constant CHAR extent in a BASED variable is invalid unless the stri=
ng is=20
a scalar or it meets all of the following conditions:=20
=96 It is the last element in a structure.=20
=96 It has no parents that are arrays.=20
=96 It has one of these attributes: UNALIGNED, NONVARYING, or VARZ.=20

> Any of the following non-constant extents in a BASED variable are valid o=
nly if=20
the variable is a scalar:=20
=96 The non-constant AREA extent=20
=96 The non-constant BIT extent=20
=96 The non-constant GRAPHIC extent=20
=96 The non-constant WIDECHAR extent
0
robin
10/14/2013 10:45:57 PM
On 14/10/2013 23:45, robin.vowels@gmail.com wrote:
> Hi Renaud,
>     Here is Peter Elderon's reply:--
>
>
> back in V3, the compiler mistakenly allowed some programs to compile that were illegal according to the LRM which stated that all extents in BASED variables must be constants ( =  restricted expressions) unless the extent was specified via REFER.
>
> A customer pointed this out and said the compiler should be enforcing the rules given in the LRM, and we started doing this 3.9
>
> However, other customers had been exploiting this feature / bug, and when we started objecting all such BASED variables, they were upset.
>
> So, we decided to allow a limited set of such BASED with non-constant extents to be supported and to document exactly what is allowed (which are the simple cases most of the customers wanted). I have included the text from the 4.2 LRM below
>
> If he change the structure to CONTROLLED and used ALLOCATE rather than LE to allocate it, then his code would work fine
>
> - Peter
>
> text from the LRM:
>
> If you do not specify the REFER option, the extent specifications in the BASED
> declarations must be restricted expressions with the following exceptions:
>
>> A non-constant array extent in a BASED variable is invalid unless the array
> meets all of the following conditions:
> � It is one dimensional.
> � The lower bound of the array is a constant.
> � When it is a part of a structure, the extents of all other fields in the structure
> are constant, and no fields follow the array and the parent structures, if any,
> of the array.
>
>> A non-constant CHAR extent in a BASED variable is invalid unless the string is
> a scalar or it meets all of the following conditions:
> � It is the last element in a structure.
> � It has no parents that are arrays.
> � It has one of these attributes: UNALIGNED, NONVARYING, or VARZ.
>
>> Any of the following non-constant extents in a BASED variable are valid only if
> the variable is a scalar:
> � The non-constant AREA extent
> � The non-constant BIT extent
> � The non-constant GRAPHIC extent
> � The non-constant WIDECHAR extent
>
It seems sensible to me, a matter of flexibility v. a strict uniformity.
0
Peter
10/15/2013 8:15:22 AM
Le mardi 15 octobre 2013 00:45:57 UTC+2, robin....@gmail.com a =E9crit=A0:
> Hi Renaud,
>=20
>    Here is Peter Elderon's reply:--
>=20

Thanks for your help Robin (and Peter).
I'll thus have to withdraw my requirement to allocate the storage from an a=
lternate heap as ALLOCATE is using the default heap.
0
renaud
10/15/2013 7:21:41 PM
I'm now converting the problematic BASED structures to CONTROLLED, and I am facing another issue.
The following is compiling correctly but generates an abend on the ALLOCATE statement:

TEST04: PROCEDURE(PARMS) OPTIONS(MAIN);                            
                                                                   
  DCL    PARMS           CHAR(255) VARYING;                        
  DCL    (LF1,LF2,LF3,LF4)  BIN FIXED(31);                         
  DCL    FWIDTH          BIN FIXED(31);                            
  DCL 01 FRULER          UNALIGNED CONTROLLED,                     
         05 HEADER,                                                
            10 FIELD1    CHAR(LF1),                                
            10 FIELD2    CHAR(LF2),                                
            10 FIELD3    CHAR(LF3),                                
            10 FIELD4    CHAR(LF4),                                
            10 FIELD5    CHAR(1),                                  
         05 FLD_DAT_TX          CHAR(FWIDTH - SIZE(FRULER.HEADER));
                                                                   
  LF1 = 1;                                                         
  LF2 = 27;                                                        
  LF3 = 1;        
  LF4 = 10;       
  FWIDTH = 80;    
                  
  ALLOCATE FRULER;
                  
END TEST04;       

IBM0855S ONCODE=3809  The length of a data aggregate exceeded the maximum limit
         From entry point TEST04 at statement 21 at compile unit offset +000001
          1E500730.                                                            
0
renaud
10/16/2013 8:17:51 PM
On 2013-10-16 20:17, renaud.giot@gmail.com wrote:
> I'm now converting the problematic BASED structures to CONTROLLED, and I am facing another issue.
> The following is compiling correctly but generates an abend on the ALLOCATE statement:
>
> TEST04: PROCEDURE(PARMS) OPTIONS(MAIN);
>
>    DCL    PARMS           CHAR(255) VARYING;
>    DCL    (LF1,LF2,LF3,LF4)  BIN FIXED(31);
>    DCL    FWIDTH          BIN FIXED(31);
>    DCL 01 FRULER          UNALIGNED CONTROLLED,
>           05 HEADER,
>              10 FIELD1    CHAR(LF1),
>              10 FIELD2    CHAR(LF2),
>              10 FIELD3    CHAR(LF3),
>              10 FIELD4    CHAR(LF4),
>              10 FIELD5    CHAR(1),
>           05 FLD_DAT_TX          CHAR(FWIDTH - SIZE(FRULER.HEADER));
>
>    LF1 = 1;
>    LF2 = 27;
>    LF3 = 1;
>    LF4 = 10;
>    FWIDTH = 80;
>
>    ALLOCATE FRULER;
>
> END TEST04;
>
> IBM0855S ONCODE=3809  The length of a data aggregate exceeded the maximum limit
>           From entry point TEST04 at statement 21 at compile unit offset +000001
>            1E500730.

I've come across a similar problem in a greyish past, code that worked with the 
V2.3.0 compiler stopped working with EPLI due to the fact that the SIZE() 
builtin does not return a sensible value for unallocated controlled storage, in 
your case "fruler.header" - Peter Elderon, if you are following this thread it 
might be useful to flag this kind of code with an 'S' type message.

Changing the fld_dat_tx into

05 fld_dat_tx char(fwidth - lf1 - lf2 - lf3 - lf4 - 1);

will do what you want. The alternative might be the use of a UNION, but that 
would mean you'd have to explain the exact usage of "fruler".

Robert

PS: As a side remark, please start writing your code in lowercase, it's so much 
more readable!
-- 
Robert AH Prins
robert(a)prino(d)org
0
Robert
10/16/2013 11:45:55 PM
On 2013-10-16 20:17, renaud.giot@gmail.com wrote:
> I'm now converting the problematic BASED structures to CONTROLLED, and I am facing another issue.
> The following is compiling correctly but generates an abend on the ALLOCATE statement:
>
> TEST04: PROCEDURE(PARMS) OPTIONS(MAIN);
>
>    DCL    PARMS           CHAR(255) VARYING;
>    DCL    (LF1,LF2,LF3,LF4)  BIN FIXED(31);
>    DCL    FWIDTH          BIN FIXED(31);
>    DCL 01 FRULER          UNALIGNED CONTROLLED,
>           05 HEADER,
>              10 FIELD1    CHAR(LF1),
>              10 FIELD2    CHAR(LF2),
>              10 FIELD3    CHAR(LF3),
>              10 FIELD4    CHAR(LF4),
>              10 FIELD5    CHAR(1),
>           05 FLD_DAT_TX          CHAR(FWIDTH - SIZE(FRULER.HEADER));
>
>    LF1 = 1;
>    LF2 = 27;
>    LF3 = 1;
>    LF4 = 10;
>    FWIDTH = 80;
>
>    ALLOCATE FRULER;
>
> END TEST04;
>
> IBM0855S ONCODE=3809  The length of a data aggregate exceeded the maximum limit
>           From entry point TEST04 at statement 21 at compile unit offset +000001
>            1E500730.

And of course with PL/I being PL/I, there are more ways to skin a cat:

dcl (lf1,lf2,lf3,lf4) fixed bin (31);
dcl fwidth            fixed bin (31);

lf1    = 1;
lf2    = 27;
lf3    = 1;
lf4    = 10;
fwidth = 80;

call sub();

sub: proc;
dcl 1 dummy,
       2 * char (lf1),
       2 * char (lf2),
       2 * char (lf3),
       2 * char (lf4),
       2 * char   (1);

dcl 1 sruler unal,
       2 header,
         3 field1     char(lf1),
         3 field2     char(lf2),
         3 field3     char(lf3),
         3 field4     char(lf4),
         3 field5     char  (1),
         3 fld_dat_tx char((fwidth - stg(dummy)));

/* And just to put something in all fields at the same time */
sruler = '....v....1....v....2....v....3....v....4....v....5';
put data(sruler);
end sub;

Robert
-- 
Robert AH Prins
robert(a)prino(d)org
0
Robert
10/17/2013 12:23:26 AM
On Thursday, October 17, 2013 7:17:51 AM UTC+11, renau...@gmail.com wrote:
> I'm now converting the problematic BASED structures to CONTROLLED, and I =
am facing another issue. The following is compiling correctly but generates=
 an abend on the ALLOCATE statement: TEST04: PROCEDURE(PARMS) OPTIONS(MAIN)=
; DCL PARMS CHAR(255) VARYING; DCL (LF1,LF2,LF3,LF4) BIN FIXED(31); DCL FWI=
DTH BIN FIXED(31); DCL 01 FRULER UNALIGNED CONTROLLED, 05 HEADER, 10 FIELD1=
 CHAR(LF1), 10 FIELD2 CHAR(LF2), 10 FIELD3 CHAR(LF3), 10 FIELD4 CHAR(LF4), =
10 FIELD5 CHAR(1), 05 FLD_DAT_TX CHAR(FWIDTH - SIZE(FRULER.HEADER)); LF1 =
=3D 1; LF2 =3D 27; LF3 =3D 1; LF4 =3D 10; FWIDTH =3D 80; ALLOCATE FRULER; E=
ND TEST04; IBM0855S ONCODE=3D3809 The length of a data aggregate exceeded t=
he maximum limit From entry point TEST04 at statement 21 at compile unit of=
fset +000001 1E500730.

R.A.H.P has hit the nail on the head.
I guess it all depends on exactly when the SIZE function is executed.
Have a look at the generated code.
0
robin
10/17/2013 12:48:27 AM
Robert AH Prins <spamtrap@prino.org> wrote:

(snip of PL/I question, and sample PL/I program)

> PS: As a side remark, please start writing your code in lowercase, 
> it's so much more readable!

Other than C, when did IBM compilers begin to accept lower case
input?

I still remember the confusion of (accidentally) writing JCL in
lower case, and then trying to debug from printed output that
maps it to upper case (on the 1403).

I also remember being confused by CMS, where EXEC2 and EXEC3 don't
accept lower case, but REXX does. 

-- glen
0
glen
10/17/2013 3:21:48 AM
On 17/10/2013 10:49, Robert AH Prins wrote:
> On 2013-10-17 03:21, glen herrmannsfeldt wrote:
>> Robert AH Prins <spamtrap@prino.org> wrote:
>>
>> (snip of PL/I question, and sample PL/I program)
>>
>>> PS: As a side remark, please start writing your code in lowercase,
>>> it's so much more readable!
>>
>> Other than C, when did IBM compilers begin to accept lower case
>> input?
>
> V2.3.0 of PL/I already accepted lowercase in the early 1990's, and I
> think I once coded, accidentally and against the then company standards,
> PL/I in lowercase with the V1.5 compiler without problems between 1985
> and 1990.
>
> Robert
At one point in time neither terminals nor printers accepted lower case. 
This gradually changed but for some time afterwards the standards at my 
installation required (sensibly) that only upper case be used, as a 
precaution against either inadvertantly or being obliged to use hardware 
that required it. In the same way, standards required the use of a small 
screen size as a precaution against an application trying to us a screen 
size large that that available.
Personally, I am happy with upper case even now and I have always had a 
thing about readability. It is not about what is nice, but about what 
does the business safely. Readability is about more that upper/lower case.
0
Peter
10/17/2013 8:14:18 AM
> Peter Elderon, if you are following this thread it might be useful to fla=
g this kind of code with an 'S' type message.

Hi Robert,

It seems it's working as designed and documented.
Here is what I found in the Language Reference manual:

=95If, in either an ALLOCATE or a DECLARE statement, bounds, lengths, or si=
zes are specified by expressions that contain references to the variable be=
ing allocated, the expressions are evaluated using the value of the most re=
cent generation of the variable. For example:=20
  declare X(N) fixed bin ctl;
  N =3D 20;
  allocate X;
  allocate X(X(1));In the first allocation of X, the upper bound is specifi=
ed by the declare statement and N =3D 20;. In the second allocation, the up=
per bound is specified by the value of the first element of the first gener=
ation of X.

In my case, there is no previous generation.
0
renaud
10/17/2013 8:30:38 AM
Peter J. Seymour <ng@pjsey.demon.co.uk> wrote:
> On 17/10/2013 10:49, Robert AH Prins wrote:

(snip, I wrote)
>>> Other than C, when did IBM compilers begin to accept lower case
>>> input?

>> V2.3.0 of PL/I already accepted lowercase in the early 1990's, and I
>> think I once coded, accidentally and against the then company standards,
>> PL/I in lowercase with the V1.5 compiler without problems between 1985
>> and 1990.

(snip)
> At one point in time neither terminals nor printers accepted lower case. 

I remember the 2741 back to about 1970 that allowed lower case.
WYLBUR by default would convert to upper case, but could be set
to preserve case. Forgetting this setting and editing JCL would
give surprising results.

Print spooled to SYSOUT=D would print on a TN print train, but
only at night. 

> This gradually changed but for some time afterwards the standards at 
> my installation required (sensibly) that only upper case be used, 
> as a precaution against either inadvertantly or being obliged to 
> use hardware that required it. In the same way, standards 
> required the use of a small screen size as a precaution 
> against an application trying to us a screen size large that 
> that available.  Personally, I am happy with upper case even 
> now and I have always had a thing about readability. 
> It is not about what is nice, but about what does the 
> business safely. Readability is about more that upper/lower case.

I am used to seeing C and Java in lower case, but Fortran and PL/I
in upper case.

Also, even though many languages now allow lines longer than 80
characters I find programs more readable, especially on more usual
sized screens, with shorter lines. (And my news host requires it.)

-- glen

0
glen
10/17/2013 8:58:10 AM
On 2013-10-17 03:21, glen herrmannsfeldt wrote:
> Robert AH Prins <spamtrap@prino.org> wrote:
>
> (snip of PL/I question, and sample PL/I program)
>
>> PS: As a side remark, please start writing your code in lowercase,
>> it's so much more readable!
>
> Other than C, when did IBM compilers begin to accept lower case
> input?

V2.3.0 of PL/I already accepted lowercase in the early 1990's, and I think I 
once coded, accidentally and against the then company standards, PL/I in 
lowercase with the V1.5 compiler without problems between 1985 and 1990.

Robert
-- 
Robert AH Prins
robert(a)prino(d)org
0
Robert
10/17/2013 9:49:00 AM
On 2013-10-17 00:23, Robert AH Prins wrote:
> On 2013-10-16 20:17, renaud.giot@gmail.com wrote:
>> I'm now converting the problematic BASED structures to CONTROLLED, and I am
>> facing another issue.
>> The following is compiling correctly but generates an abend on the ALLOCATE
>> statement:
>>
>> TEST04: PROCEDURE(PARMS) OPTIONS(MAIN);
>>
>>    DCL    PARMS           CHAR(255) VARYING;
>>    DCL    (LF1,LF2,LF3,LF4)  BIN FIXED(31);
>>    DCL    FWIDTH          BIN FIXED(31);
>>    DCL 01 FRULER          UNALIGNED CONTROLLED,
>>           05 HEADER,
>>              10 FIELD1    CHAR(LF1),
>>              10 FIELD2    CHAR(LF2),
>>              10 FIELD3    CHAR(LF3),
>>              10 FIELD4    CHAR(LF4),
>>              10 FIELD5    CHAR(1),
>>           05 FLD_DAT_TX          CHAR(FWIDTH - SIZE(FRULER.HEADER));
>>
>>    LF1 = 1;
>>    LF2 = 27;
>>    LF3 = 1;
>>    LF4 = 10;
>>    FWIDTH = 80;
>>
>>    ALLOCATE FRULER;
>>
>> END TEST04;
>>
>> IBM0855S ONCODE=3809  The length of a data aggregate exceeded the maximum limit
>>           From entry point TEST04 at statement 21 at compile unit offset +000001
>>            1E500730.
>
> And of course with PL/I being PL/I, there are more ways to skin a cat:
>
> dcl (lf1,lf2,lf3,lf4) fixed bin (31);
> dcl fwidth            fixed bin (31);
>
> lf1    = 1;
> lf2    = 27;
> lf3    = 1;
> lf4    = 10;
> fwidth = 80;
>
> call sub();
>
> sub: proc;
> dcl 1 dummy,
>        2 * char (lf1),
>        2 * char (lf2),
>        2 * char (lf3),
>        2 * char (lf4),
>        2 * char   (1);
>
> dcl 1 sruler unal,
>        2 header,
>          3 field1     char(lf1),
>          3 field2     char(lf2),
>          3 field3     char(lf3),
>          3 field4     char(lf4),
>          3 field5     char  (1),
>          3 fld_dat_tx char((fwidth - stg(dummy)));
>
> /* And just to put something in all fields at the same time */
> sruler = '....v....1....v....2....v....3....v....4....v....5';
> put data(sruler);
> end sub;

While testing the above, I added my (non-)standard PLITABS, i.e.

dcl 1 plitabs ext,
       2 offset      fixed bin (15) init    (14),
       2 pagesize    fixed bin (15) init (32766),
       2 linesize    fixed bin (15) init   (255),
       2 pagelength  fixed bin (15) init (32767),
       2 reserved1   fixed bin (15) init     (0),
       2 reserved2   fixed bin (15) init     (0),
       2 reserved3   fixed bin (15) init     (0),
       2 no_of_tabs  fixed bin (15) init     (0),
       2 tab(10)     fixed bin (15) init    (25,  49,  73,  97, 121,
                                            145, 169, 193, 217, 241);

to print the output on a one-field per line format. Much to my surprise, EPLI 
V3.9 does not honer this and the output of a "put data(plitabs);" appears as, 
limited to 72 characters:

*********************************************************************
1PLITABS.OFFSET=       14                        PLITABS.PAGESIZE=
  PLITABS.LINESIZE=      255                      PLITABS.PAGELENGTH=
  PLITABS.RESERVED1=        0                     PLITABS.RESERVED2=
  PLITABS.RESERVED3=        0                     PLITABS.NO_OF_TABS=
                          PLITABS.TAB(2)=       49
  PLITABS.TAB(4)=       97                        PLITABS.TAB(5)=
                          PLITABS.TAB(7)=      169
  PLITABS.TAB(9)=      217                        PLITABS.TAB(10)=
******************************************************************** B

whereas in V2.3.0, I get the expected output, i.e.

*****************************
1PLITABS.OFFSET=       14
  PLITABS.PAGESIZE=    32760
  PLITABS.LINESIZE=      255
  PLITABS.PAGELENGTH=    32762
  PLITABS.RESERVED1=        0
  PLITABS.RESERVED2=        0
  PLITABS.RESERVED3=        0
  PLITABS.NO_OF_TABS=        0
  PLITABS.TAB(1)=       25
  PLITABS.TAB(2)=       49
  PLITABS.TAB(3)=       73
  PLITABS.TAB(4)=       97
  PLITABS.TAB(5)=      121
  PLITABS.TAB(6)=      145
  PLITABS.TAB(7)=      169
  PLITABS.TAB(8)=      193
  PLITABS.TAB(9)=      217
  PLITABS.TAB(10)=   	   241;
*****************************

The manuals do not detail any changes, so why doesn't EPLI 3.9 honour the settings?

Robert
-- 
Robert AH Prins
robert(a)prino(d)org
0
Robert
10/17/2013 10:39:20 AM
On Thursday, October 17, 2013 8:44:34 AM UTC+11, Robert AH Prins wrote:
PS: As a side remark, please start writing your code in lowercase,
> it's so much more readable!

CODE IN UPPER CASE IS VERY READABLE.
0
robin
10/17/2013 11:58:44 AM
On Thursday, October 17, 2013 6:47:38 PM UTC+11, Robert AH Prins wrote: > O=
n 2013-10-17 03:21, glen herrmannsfeldt wrote: > Robert AH Prins <spamtrap@=
prino.org> wrote: > > (snip of PL/I question, and sample PL/I program) > >>=
 PS: As a side remark, please start writing your code in lowercase, >> it's=
 so much more readable! > > Other than C, when did IBM compilers begin to a=
ccept lower case > input? V2.3.0 of PL/I already accepted lowercase in the =
early 1990's, and I think I once coded, accidentally and against the then c=
ompany standards, PL/I in lowercase with the V1.5 compiler without problems=
 between 1985 and 1990.

I've used some lower case in PL/I code prior to 1970.
Lower case in S/360 assembler since about 1980.
0
robin
10/17/2013 12:04:48 PM
On Thursday, October 17, 2013 7:14:18 PM UTC+11, Peter J. Seymour wrote: > =
On 17/10/2013 10:49, Robert AH Prins wrote: > On 2013-10-17 03:21, glen her=
rmannsfeldt wrote: >> Robert AH Prins <spamtrap@prino.org> wrote: >> >> (sn=
ip of PL/I question, and sample PL/I program) >> >>> PS: As a side remark, =
please start writing your code in lowercase, >>> it's so much more readable=
! >> >> Other than C, when did IBM compilers begin to accept lower case >> =
input? > > V2.3.0 of PL/I already accepted lowercase in the early 1990's, a=
nd I > think I once coded, accidentally and against the then company standa=
rds, > PL/I in lowercase with the V1.5 compiler without problems between 19=
85 > and 1990. > > Robert At one point in time neither terminals nor printe=
rs accepted lower case. This gradually changed but for some time afterwards=
 the standards at my installation required (sensibly) that only upper case =
be used, as a precaution against either inadvertantly or being obliged to u=
se hardware that required it. In the same way, standards required the use o=
f a small screen size as a precaution against an application trying to us a=
 screen size large that that available. Personally, I am happy with upper c=
ase even now and I have always had a thing about readability. It is not abo=
ut what is nice, but about what does the business safely. Readability is ab=
out more that upper/lower case.

Printing terminals having upper/lower-case were available by the mid-1960s.

The Friden flexowriters were a notable case. An upper/lower case version of=
 the Teletype ASR 33 (the ASR 38), was offered.  Not sure of the year.

Terminet printers offered upper/lower case.

IBM sold upper and lower-case print trains for the S/360 from 1966.
0
robin
10/17/2013 12:12:21 PM
On 2013-10-16 23:45:55 +0000, Robert AH Prins said:

> On 2013-10-16 20:17, renaud.giot@gmail.com wrote:
>> I'm now converting the problematic BASED structures to CONTROLLED, and 
>> I am facing another issue.
>> The following is compiling correctly but generates an abend on the 
>> ALLOCATE statement:
>> 
>> TEST04: PROCEDURE(PARMS) OPTIONS(MAIN);
>> 
>> DCL    PARMS           CHAR(255) VARYING;
>> DCL    (LF1,LF2,LF3,LF4)  BIN FIXED(31);
>> DCL    FWIDTH          BIN FIXED(31);
>> DCL 01 FRULER          UNALIGNED CONTROLLED,
>> 05 HEADER,
>> 10 FIELD1    CHAR(LF1),
>> 10 FIELD2    CHAR(LF2),
>> 10 FIELD3    CHAR(LF3),
>> 10 FIELD4    CHAR(LF4),
>> 10 FIELD5    CHAR(1),
>> 05 FLD_DAT_TX          CHAR(FWIDTH - SIZE(FRULER.HEADER));
>> 
>> LF1 = 1;
>> LF2 = 27;
>> LF3 = 1;
>> LF4 = 10;
>> FWIDTH = 80;
>> 
>> ALLOCATE FRULER;
>> 
>> END TEST04;
>> 
>> IBM0855S ONCODE=3809  The length of a data aggregate exceeded the maximum limit
>> From entry point TEST04 at statement 21 at compile unit offset +000001
>> 1E500730.
> 
> I've come across a similar problem in a greyish past, code that worked 
> with the V2.3.0 compiler stopped working with EPLI due to the fact that 
> the SIZE() builtin does not return a sensible value for unallocated 
> controlled storage, in your case "fruler.header" - Peter Elderon, if 
> you are following this thread it might be useful to flag this kind of 
> code with an 'S' type message.

The problem is that, in this case, FRULER.HEADER is being taken to mean 
the size of the FRULER.HEADER in the zeroth allocation on the stack, 
which doesn't exist.

A compiler diagnostic in this case cannot be more than W; the code is 
legal, and theoretically correct; it just doesn't do what is obviously 
intended by the author.


> 
> Changing the fld_dat_tx into
> 
> 05 fld_dat_tx char(fwidth - lf1 - lf2 - lf3 - lf4 - 1);
> 
> will do what you want. The alternative might be the use of a UNION, but 
> that would mean you'd have to explain the exact usage of "fruler".
> 
> Robert
> 
> PS: As a side remark, please start writing your code in lowercase, it's 
> so much more readable!


-- 
John W Kennedy
A proud member of the reality-based community.

0
John
10/17/2013 2:37:19 PM
On 2013-10-17 03:21:48 +0000, glen herrmannsfeldt said:

> Robert AH Prins <spamtrap@prino.org> wrote:
> 
> (snip of PL/I question, and sample PL/I program)
> 
>> PS: As a side remark, please start writing your code in lowercase,
>> it's so much more readable!
> 
> Other than C, when did IBM compilers begin to accept lower case
> input?

The PL/I Optimizer and Checker always did. Even (F) may have, but my 
slight weeks of experience on CP/67 45 years ago have not left me with 
adequate memories.


-- 
John W Kennedy
"...when you're trying to build a house of cards, the last thing you 
should do is blow hard and wave your hands like a madman."
  --  Rupert Goodwins

0
John
10/17/2013 2:42:58 PM
On 2013-10-17 00:48:27 +0000, robin.vowels@gmail.com said:

> On Thursday, October 17, 2013 7:17:51 AM UTC+11, renau...@gmail.com wrote:
>> I'm now converting the problematic BASED structures to CONTROLLED, and 
>> I am facing another issue. The following is compiling correctly but 
>> generates an abend on the ALLOCATE statement: TEST04: PROCEDURE(PARMS) 
>> OPTIONS(MAIN); DCL PARMS CHAR(255) VARYING; DCL (LF1,LF2,LF3,LF4) BIN 
>> FIXED(31); DCL FWIDTH BIN FIXED(31); DCL 01 FRULER UNALIGNED 
>> CONTROLLED, 05 HEADER, 10 FIELD1 CHAR(LF1), 10 FIELD2 CHAR(LF2), 10 
>> FIELD3 CHAR(LF3), 10 FIELD4 CHAR(LF4), 10 FIELD5 CHAR(1), 05 FLD_DAT_TX 
>> CHAR(FWIDTH - SIZE(FRULER.HEADER)); LF1 = 1; LF2 = 27; LF3 = 1; LF4 = 
>> 10; FWIDTH = 80; ALLOCATE FRULER; END TEST04; IBM0855S ONCODE=3809 The 
>> length of a data aggregate exceeded the maximum limit From entry point 
>> TEST04 at statement 21 at compile unit offset +000001 1E500730.
> 
> R.A.H.P has hit the nail on the head.
> I guess it all depends on exactly when the SIZE function is executed.
> Have a look at the generated code.

You don't need to examine the generated code. The SIZE function is 
executed before the allocation by definition. Even Ada does not 
linearly elaborate within structures, and PL/I does not linearly 
elaborate at all.

-- 
John W Kennedy
"Compact is becoming contract,
Man only earns and pays."
  -- Charles Williams.  "Bors to Elayne:  On the King's Coins"

0
John
10/17/2013 2:50:03 PM
On 10/16/2013 8:48 PM, robin.vowels@gmail.com wrote:
> On Thursday, October 17, 2013 7:17:51 AM UTC+11, renau...@gmail.com wrote:
>> I'm now converting the problematic BASED structures to CONTROLLED, and I am facing another issue. The following is compiling correctly but generates an abend on the ALLOCATE statement: TEST04: PROCEDURE(PARMS) OPTIONS(MAIN); DCL PARMS CHAR(255) VARYING; DCL (LF1,LF2,LF3,LF4) BIN FIXED(31); DCL FWIDTH BIN FIXED(31); DCL 01 FRULER UNALIGNED CONTROLLED, 05 HEADER, 10 FIELD1 CHAR(LF1), 10 FIELD2 CHAR(LF2), 10 FIELD3 CHAR(LF3), 10 FIELD4 CHAR(LF4), 10 FIELD5 CHAR(1), 05 FLD_DAT_TX CHAR(FWIDTH - SIZE(FRULER.HEADER)); LF1 = 1; LF2 = 27; LF3 = 1; LF4 = 10; FWIDTH = 80; ALLOCATE FRULER; END TEST04; IBM0855S ONCODE=3809 The length of a data aggregate exceeded the maximum limit From entry point TEST04 at statement 21 at compile unit offset +000001 1E500730.
>
> R.A.H.P has hit the nail on the head.
> I guess it all depends on exactly when the SIZE function is executed.
> Have a look at the generated code.
>

Yes, I see the conundrum. the size is computed during allocation, but 
exactly _when_ during allocation.  You would expect the member 
declarations to be processed in order so that the declaration of 
FLD_DAT_TX is processed after the others, but the language standard 
doesn't say anything about this.

-- 
Pete
0
Peter
10/17/2013 6:59:03 PM
On 10/17/2013 4:58 AM, glen herrmannsfeldt wrote:
>
> Also, even though many languages now allow lines longer than 80
> characters I find programs more readable, especially on more usual
> sized screens, with shorter lines. (And my news host requires it.)
>

I agree.  I always now try to stick to 80 (having abandoned the 2-72 
convention some time ago).  Too long a line can be difficult to read.

-- 
Pete
0
Peter
10/17/2013 7:02:44 PM
On 10/17/2013 8:04 AM, robin.vowels@gmail.com wrote:
> On Thursday, October 17, 2013 6:47:38 PM UTC+11, Robert AH Prins wrote: > On 2013-10-17 03:21, glen herrmannsfeldt wrote: > Robert AH Prins <spamtrap@prino.org> wrote: > > (snip of PL/I question, and sample PL/I program) > >> PS: As a side remark, please start writing your code in lowercase, >> it's so much more readable! > > Other than C, when did IBM compilers begin to accept lower case > input? V2.3.0 of PL/I already accepted lowercase in the early 1990's, and I think I once coded, accidentally and against the then company standards, PL/I in lowercase with the V1.5 compiler without problems between 1985 and 1990.
>
> I've used some lower case in PL/I code prior to 1970.
> Lower case in S/360 assembler since about 1980.
>

Once we abandoned keypunches and uppercase-only terminals coding in 
lower-case became simpler.

-- 
Pete
0
Peter
10/17/2013 7:05:21 PM
On 10/17/2013 10:42 AM, John W Kennedy wrote:
> On 2013-10-17 03:21:48 +0000, glen herrmannsfeldt said:
>
>> Robert AH Prins <spamtrap@prino.org> wrote:
>>
>> (snip of PL/I question, and sample PL/I program)
>>
>>> PS: As a side remark, please start writing your code in lowercase,
>>> it's so much more readable!
>>
>> Other than C, when did IBM compilers begin to accept lower case
>> input?
>
> The PL/I Optimizer and Checker always did. Even (F) may have, but my
> slight weeks of experience on CP/67 45 years ago have not left me with
> adequate memories.
>

(F) stored all text internally in sixbit encoding.


-- 
Pete
0
Peter
10/17/2013 7:07:48 PM
Peter Flass <Peter_Flass@yahoo.com> wrote:

(snip, I wrote)

>>> Other than C, when did IBM compilers begin to accept lower case
>>> input?

(snip)

> (F) stored all text internally in sixbit encoding.

(F) has comments like:


*              (1) CHARACTER CODE DEPENDENCY.
*              THE OPERATION OF THIS MODULE DEPENDS UPON AN INTERNAL
*        REPRESENTATION OF THE EXTERNAL CHARACTER SET WHICH IS
*        EQUIVALENT TO THE ONE USED AT ASSEMBLY TIME. THE CODING HAS
*        BEEN ARRANGED SO THAT REDEFINITION OF 'CHARACTER' CONSTANTS,
*        BY RE-ASSEMBLY, WILL RESULT IN A CORRECT MODULE FOR THE NEW
*        DEFINITIONS.

That would seem to indicate that it doesn't make assumptions about
the bit patterns. There are no lower case character constants in (F).

-- glen
0
glen
10/17/2013 7:59:09 PM
Peter Flass <Peter_Flass@yahoo.com> wrote:

(snip)

>> R.A.H.P has hit the nail on the head.
>> I guess it all depends on exactly when the SIZE function is executed.
>> Have a look at the generated code.
 
> Yes, I see the conundrum. the size is computed during allocation, 
> but exactly _when_ during allocation.  You would expect the member 
> declarations to be processed in order so that the declaration of 
> FLD_DAT_TX is processed after the others, but the language standard 
> doesn't say anything about this.

Not having actually read it, it seems that some are indicating that
it applies to the previous generation of the variable (if any).

I can see that might be useful sometimes.

-- glen
0
glen
10/17/2013 8:03:03 PM
On Friday, October 18, 2013 6:07:48 AM UTC+11, Peter Flass wrote:
> (F) stored all text internally in sixbit encoding.

What about character constants?
0
robin
10/18/2013 3:09:02 AM
On Friday, October 18, 2013 1:50:03 AM UTC+11, John W Kennedy wrote:
> On 2013-10-17 00:48:27 +0000, ro.....@gmail.com said: > On Thursday, Octo=
ber 17, 2013 7:17:51 AM UTC+11, renau...@gmail.com wrote: >> I'm now conver=
ting the problematic BASED structures to CONTROLLED, and >> I am facing ano=
ther issue. The following is compiling correctly but >> generates an abend =
on the ALLOCATE statement: TEST04: PROCEDURE(PARMS) >> OPTIONS(MAIN); DCL P=
ARMS CHAR(255) VARYING; DCL (LF1,LF2,LF3,LF4) BIN >> FIXED(31); DCL FWIDTH =
BIN FIXED(31); DCL 01 FRULER UNALIGNED >> CONTROLLED, 05 HEADER, 10 FIELD1 =
CHAR(LF1), 10 FIELD2 CHAR(LF2), 10 >> FIELD3 CHAR(LF3), 10 FIELD4 CHAR(LF4)=
, 10 FIELD5 CHAR(1), 05 FLD_DAT_TX >> CHAR(FWIDTH - SIZE(FRULER.HEADER)); L=
F1 =3D 1; LF2 =3D 27; LF3 =3D 1; LF4 =3D >> 10; FWIDTH =3D 80; ALLOCATE FRU=
LER; END TEST04; IBM0855S ONCODE=3D3809 The >> length of a data aggregate e=
xceeded the maximum limit From entry point >> TEST04 at statement 21 at com=
pile unit offset +000001 1E500730.=20
> > R.A.H.P has hit the nail on the head.=20
>> I guess it all depends on exactly when the SIZE function is executed.=20
>> Have a look at the generated code.

> You don't need to examine the generated code.

You do if you want to know when SIZE is executed in relation
to everything else.

> The SIZE function is
> executed before the allocation by definition.

And where dies it say that?

> Even Ada does not linearly elaborate within structures, and PL/I does not=
 linearly elaborate at all.

That's not correct.

In structures that use REFER for size or length,
the item referred to MUST precede all variable-langth fields.
0
robin
10/18/2013 4:29:20 AM
On 10/18/2013 12:29 AM, robin.vowels@gmail.com wrote:
> On Friday, October 18, 2013 1:50:03 AM UTC+11, John W Kennedy wrote:
>> On 2013-10-17 00:48:27 +0000, ro.....@gmail.com said: > On Thursday, October 17, 2013 7:17:51 AM UTC+11, renau...@gmail.com wrote: >> I'm now converting the problematic BASED structures to CONTROLLED, and >> I am facing another issue. The following is compiling correctly but >> generates an abend on the ALLOCATE statement: TEST04: PROCEDURE(PARMS) >> OPTIONS(MAIN); DCL PARMS CHAR(255) VARYING; DCL (LF1,LF2,LF3,LF4) BIN >> FIXED(31); DCL FWIDTH BIN FIXED(31); DCL 01 FRULER UNALIGNED >> CONTROLLED, 05 HEADER, 10 FIELD1 CHAR(LF1), 10 FIELD2 CHAR(LF2), 10 >> FIELD3 CHAR(LF3), 10 FIELD4 CHAR(LF4), 10 FIELD5 CHAR(1), 05 FLD_DAT_TX >> CHAR(FWIDTH - SIZE(FRULER.HEADER)); LF1 = 1; LF2 = 27; LF3 = 1; LF4 = >> 10; FWIDTH = 80; ALLOCATE FRULER; END TEST04; IBM0855S ONCODE=3809 The >> length of a data aggregate exceeded the maximum limit From entry point >> TEST04 at statement 21 at compile unit offset +000001 1E500730.
>>> R.A.H.P has hit the nail on the head.
>>> I guess it all depends on exactly when the SIZE function is executed.
>>> Have a look at the generated code.
>
>> You don't need to examine the generated code.
>
> You do if you want to know when SIZE is executed in relation
> to everything else.
>
>> The SIZE function is
>> executed before the allocation by definition.
>
> And where dies it say that?
>
>> Even Ada does not linearly elaborate within structures, and PL/I does not linearly elaborate at all.
>
> That's not correct.
>
> In structures that use REFER for size or length,
> the item referred to MUST precede all variable-langth fields.
>

This example doesn't use REFER.

-- 
Pete
0
Peter
10/18/2013 11:42:24 AM
On 10/17/2013 11:09 PM, robin.vowels@gmail.com wrote:
> On Friday, October 18, 2013 6:07:48 AM UTC+11, Peter Flass wrote:
>> (F) stored all text internally in sixbit encoding.
>
> What about character constants?
>

Except them.

-- 
Pete
0
Peter
10/18/2013 11:42:42 AM
On Friday, October 18, 2013 10:42:24 PM UTC+11, Peter Flass wrote:
> On 10/18/2013 12:29 AM, r.....@g.com wrote: > On Friday, October 18, 2013 1:50:03 AM UTC+11, John W Kennedy wrote: >> On 2013-10-17 00:48:27 +0000

>> Even Ada does not linearly elaborate within structures, and PL/I does not linearly elaborate at all. 

> > That's not correct.
> > In structures that use REFER for size or length,
> > the item referred to MUST precede all variable-langth fields.

> This example doesn't use REFER.

The discussion is about "linear elaboration", for which REFER is entirely
relevant.
0
robin
10/18/2013 12:09:22 PM
On Friday, October 18, 2013 10:42:42 PM UTC+11, Peter Flass wrote:
> On 10/17/2013 11:09 PM, nospam@gmail.com wrote:
> On Friday, October 18, 2013 6:07:48 AM UTC+11, Peter Flass wrote:

>> (F) stored all text internally in sixbit encoding.

> > What about character constants?

 > Except them.

I'm a bit [no pun intended] puzzled about this 6-bit thing.
It's not exactly a convenient size, like 6 into 32 doesn't go.
The nature of the machine is 8-bit characters, not 6-bit.
So the natural thought is for 8-bit characters for each of the tokens
that are special characters, with some more reserved for composite
characters stored as an 8-bit quantity.

0
robin
10/18/2013 12:18:42 PM
On 2013-10-18 04:29:20 +0000, robin.vowels@gmail.com said:

> On Friday, October 18, 2013 1:50:03 AM UTC+11, John W Kennedy wrote:
>> On 2013-10-17 00:48:27 +0000, ro.....@gmail.com said: > On Thursday, 
>> October 17, 2013 7:17:51 AM UTC+11, renau...@gmail.com wrote: >> I'm 
>> now converting the problematic BASED structures to CONTROLLED, and >> I 
>> am facing another issue. The following is compiling correctly but >> 
>> generates an abend on the ALLOCATE statement: TEST04: PROCEDURE(PARMS) 
>> >> OPTIONS(MAIN); DCL PARMS CHAR(255) VARYING; DCL (LF1,LF2,LF3,LF4) 
>> BIN >> FIXED(31); DCL FWIDTH BIN FIXED(31); DCL 01 FRULER UNALIGNED >> 
>> CONTROLLED, 05 HEADER, 10 FIELD1 CHAR(LF1), 10 FIELD2 CHAR(LF2), 10 >> 
>> FIELD3 CHAR(LF3), 10 FIELD4 CHAR(LF4), 10 FIELD5 CHAR(1), 05 FLD_DAT_TX 
>> >> CHAR(FWIDTH - SIZE(FRULER.HEADER)); LF1 = 1; LF2 = 27; LF3 = 1; LF4 
>> = >> 10; FWIDTH = 80; ALLOCATE FRULER; END TEST04; IBM0855S ONCODE=3809 
>> The >> length of a data aggregate exceeded the maximum limit From entry 
>> point >> TEST04 at statement 21 at compile unit offset +000001 
>> 1E500730.> > R.A.H.P has hit the nail on the head.>> I guess it all 
>> depends on exactly when the SIZE function is executed.>> Have a look at 
>> the generated code.
> 
>> You don't need to examine the generated code.
> 
> You do if you want to know when SIZE is executed in relation
> to everything else.
> 
>> The SIZE function is
>> executed before the allocation by definition.
> 
> And where dies it say that?

Under "ALLOCATE statement for controlled variables", quaintly enough.

>> Even Ada does not linearly elaborate within structures, and PL/I does 
>> not linearly elaborate at all.
> 
> That's not correct.
> 
> In structures that use REFER for size or length,
> the item referred to MUST precede all variable-langth fields.

What the manual says is only that the REFERred-to variable must precede 
the item containing the REFER. That is not a question of linear 
elaboration, but of mere logical possibility, since the opposite would 
require the compiled code to know the value of the variable in order to 
find its location, quod absurdum est.

-- 
John W Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
  -- Charles Williams.  "Judgement at Chelmsford"

0
John
10/18/2013 2:31:17 PM
On 10/18/2013 8:09 AM, robin.vowels@gmail.com wrote:
> On Friday, October 18, 2013 10:42:24 PM UTC+11, Peter Flass wrote:
>> On 10/18/2013 12:29 AM, r.....@g.com wrote: > On Friday, October 18, 2013 1:50:03 AM UTC+11, John W Kennedy wrote: >> On 2013-10-17 00:48:27 +0000
>
>>> Even Ada does not linearly elaborate within structures, and PL/I does not linearly elaborate at all.
>
>>> That's not correct.
>>> In structures that use REFER for size or length,
>>> the item referred to MUST precede all variable-langth fields.
>
>> This example doesn't use REFER.
>
> The discussion is about "linear elaboration", for which REFER is entirely
> relevant.
>

I disagree.  REFER is specifically defined to require linear elaboration 
for those specific cases.  Structure declarations (and CONTROLLED 
allocations) are processed "inside-out", to compute padding for the 
innermost minor structure first and then working outwards.  This is 
different from COBOL, which processes linearly and inserts padding as 
the need arises.  I think C does this also, with some additional funky 
rules.

-- 
Pete
0
Peter
10/18/2013 2:33:36 PM
On 10/18/2013 8:18 AM, robin.vowels@gmail.com wrote:
> On Friday, October 18, 2013 10:42:42 PM UTC+11, Peter Flass wrote:
>> On 10/17/2013 11:09 PM, nospam@gmail.com wrote:
>> On Friday, October 18, 2013 6:07:48 AM UTC+11, Peter Flass wrote:
>
>>> (F) stored all text internally in sixbit encoding.
>
>>> What about character constants?
>
>   > Except them.
>
> I'm a bit [no pun intended] puzzled about this 6-bit thing.
> It's not exactly a convenient size, like 6 into 32 doesn't go.
> The nature of the machine is 8-bit characters, not 6-bit.
> So the natural thought is for 8-bit characters for each of the tokens
> that are special characters, with some more reserved for composite
> characters stored as an 8-bit quantity.
>

Could be, it's been a few years since I looked.

-- 
Pete
0
Peter
10/18/2013 2:34:55 PM
On 2013-10-18 14:33:36 +0000, Peter Flass said:

> On 10/18/2013 8:09 AM, robin.vowels@gmail.com wrote:
>> On Friday, October 18, 2013 10:42:24 PM UTC+11, Peter Flass wrote:
>>> On 10/18/2013 12:29 AM, r.....@g.com wrote: > On Friday, October 18, 
>>> 2013 1:50:03 AM UTC+11, John W Kennedy wrote: >> On 2013-10-17 00:48:27 
>>> +0000
>> 
>>>> Even Ada does not linearly elaborate within structures, and PL/I does 
>>>> not linearly elaborate at all.
>> 
>>>> That's not correct.
>>>> In structures that use REFER for size or length,
>>>> the item referred to MUST precede all variable-langth fields.
>> 
>>> This example doesn't use REFER.
>> 
>> The discussion is about "linear elaboration", for which REFER is entirely
>> relevant.
>> 
> 
> I disagree.  REFER is specifically defined to require linear 
> elaboration for those specific cases.  Structure declarations (and 
> CONTROLLED allocations) are processed "inside-out", to compute padding 
> for the innermost minor structure first and then working outwards.  
> This is different from COBOL, which processes linearly and inserts 
> padding as the need arises.  I think C does this also, with some 
> additional funky rules.

"Linear elaboration" means more than that; essentially, it means that 
declarations "happen" from top to bottom. To take a trivial example, 
this (rather silly) Ada program is legal and well defined:

with Ada.Text_IO, Ada.Integer_Text_IO;
use Ada.Text_IO, Ada.Integer_Text_IO;
procedure foo is
    i: integer := 1;     -- Now i is declared
    j: integer := i + 1; -- and j can refer to it.
begin
    put (j); new_line;
end;

The obvious PL/I translation is not, because all PL/I declarations in a 
block "happen" at the same time.

foo: procedure options (main);
    declare i fixed binary initial (1);
    declare j fixed binary initial (i + 1); /* Wrong! */
    put list (j); put skip;
end;

But since this is talking about a feature that PL/I /doesn't/ have, 
it's of marginal relevance.

-- 
John W Kennedy
"...when you're trying to build a house of cards, the last thing you 
should do is blow hard and wave your hands like a madman."
  --  Rupert Goodwins

0
John
10/18/2013 6:00:38 PM
robin.vowels@gmail.com wrote:

(snip)

> I'm a bit [no pun intended] puzzled about this 6-bit thing.
> It's not exactly a convenient size, like 6 into 32 doesn't go.
> The nature of the machine is 8-bit characters, not 6-bit.
> So the natural thought is for 8-bit characters for each of the tokens
> that are special characters, with some more reserved for composite
> characters stored as an 8-bit quantity.

SIXBIT is used by DEC 36 bit systems, which store six characters
from half the ASCII set in a 36 bit word. That is, for example, used
by file names in directories, and also for symbolic names in
assemblers and compilers (and object programs).

ASCII text on 36 bit systems is five characters per word.

PDP-11 systems use Radix 50 to store a smaller ASCII subset,
three characters in a 16 bit word, for similar purposes.

-- glen
0
glen
10/18/2013 6:31:11 PM
In <l3nl4c$tup$1@speranza.aioe.org>, on 10/17/2013
   at 03:21 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>I also remember being confused by CMS, where EXEC2 and EXEC3

I know EXEC, EXEC2 and REXX, but WTF is EXEC3? Or is this a case where
I'll wish I didn't know?

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
Shmuel
10/18/2013 7:12:24 PM
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
> In <l3nl4c$tup$1@speranza.aioe.org>, on 10/17/2013
>   at 03:21 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
 
>>I also remember being confused by CMS, where EXEC2 and EXEC3
 
> I know EXEC, EXEC2 and REXX, but WTF is EXEC3? Or is this a case where
> I'll wish I didn't know?

Oh, yes, off by one.

Now, why is it that there is JES2 and JES3, but no JES1?

Some years ago, I was assembling from source, and running PL/I (F)
on an AT/370. 

To generate the file of commands to assemble the hundreds of source
files, I generated them on another computer and transfered them over.

It took a few tries before I figured out why some would work and some
not.

-- glen
 
0
glen
10/18/2013 7:12:48 PM
In <u%M7u.159986$Jf5.101580@fx09.fr7>, on 10/17/2013
   at 09:14 AM, "Peter J. Seymour" <ng@pjsey.demon.co.uk> said:

>At one point in time neither terminals nor printers accepted lower
>case. 

Maybe in the 1950's. Certainly not since ATS came out.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
Shmuel
10/18/2013 7:14:33 PM
In <l3pbuv$guu$2@dont-email.me>, on 10/17/2013
   at 03:02 PM, Peter Flass <Peter_Flass@Yahoo.com> said:

>I agree.  I always now try to stick to 80 (having abandoned the 
>2-72 convention some time ago).  

Sequence numbers are convenient..

>Too long a line can be difficult to read.

Indeed; even after I started using RECFM=VB for PL/I, I kept most of
my code well below LRECL due to readability considerations.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
Shmuel
10/18/2013 7:18:25 PM
Peter Flass wrote:
> On 10/17/2013 11:09 PM, robin.vowels@gmail.com wrote:
>> On Friday, October 18, 2013 6:07:48 AM UTC+11, Peter Flass wrote:
>>> (F) stored all text internally in sixbit encoding.
>>
>> What about character constants?
>>
>
> Except them.
>
You are confusing the subset of characters used to write language statements and the internal encoding of character data.

As I recall, the F compiler had two possible external encodings for source input: BCD (64 characters, 63 if coming from 
7-track even parity tape) and EBCDIC (256 characters). Regardless of the external encoding, the internal encoding was 
the host machine's character encoding.

Although the PL/I language is supposed to be machine independent, the F compiler ran on the IBM 360 and its equivalents 
and successors. The 360 could store character data either in EBCDIC or ASCII-8. There was a PSW bit that specified 
which. I never encountered an installation that used anything but EBCDIC. I don't know if the F compiler worked with the 
ASCII bit set or not.

Independent of the encoding used to input source programs and how the characters, once read, are encoded internally is 
the subset of the available characters used to express source programs (other than character constants and comments). 
Here there were two choices: the 60 character set and the 48 character set. The 48 character set consisted of 26 
letters, 10 digits, blank, and eleven special characters: + - * / ( ) = . , ' $ Other "characters" essential to express 
the language were composite: AND OR CAT GT LT GE etc. Most require special spacing rules to render them unambiguous .. 
represented the colon, ,. the semi colon etc. Even the 60 character set with twelve additional special characters needs 
quite a few composite symbols: ** || -> >= <= etc.

The reason for having the 48 character set was to facilitate input preparation on 024 and 026 keypunches and to 
accommodate old unit record printers (403s and 407s) that only had 48 printable characters. To make matters worse, most 
installations had printers for which the codes for + ( ) and ' printed as & % losenge and @. Reading such printouts was 
not for the faint of heart.

Even now PL/I still basically uses the 60 character set to express programs. The 26 lower case letters are allowed but 
are essentially equivalent to their corresponding upper case versions. There are also a few options to accommodate 
foreign language characters and currency symbols.

With PC implementations, source code is written using the 60 character set with the addition of the 26 lower case 
letters stored internally using ASCII-8.
0
James
10/18/2013 10:40:48 PM
On 2013-10-18 19:12:48 +0000, glen herrmannsfeldt said:

> Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
>> In <l3nl4c$tup$1@speranza.aioe.org>, on 10/17/2013
>> at 03:21 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
> 
>>> I also remember being confused by CMS, where EXEC2 and EXEC3
> 
>> I know EXEC, EXEC2 and REXX, but WTF is EXEC3? Or is this a case where
>> I'll wish I didn't know?
> 
> Oh, yes, off by one.
> 
> Now, why is it that there is JES2 and JES3, but no JES1?

I don't know how far you go back, but when IBM announced virtual memory 
for the 370, it announced two successor products to OS/360: OS/VS1, 
based on OS/360 MFT, and OS/VS2, based on OS/360 MVT. (Sometimes the 
two were collectively known as OS/VS, but they were always two 
different products.) OS/VS1 had a SPOOLing system named "JES". It was 
only later, when OS/VS2 was split into SVS (a new name for the original 
OS/VS2) and MVS (a new version) that the old add-on products HASP and 
ASP were renamed JES2 and JES3, and made standard parts of the system.

OS/360: SAM SPOOLing, optionally replaced by HASP or ASP

OS/VS1: JES

OS/VS2 1.x (later known as SVS): SAM SPOOLing, optionally replaced by 
HASP or ASP

OS/VS2 2.0 and up (MVS): JES2 (based on HASP) or JES3 (based on ASP)

Sometimes JES has been called "JES1", but never officially

The fact that HASP and ASP were add-on programs, and two different 
add-on programs at that, are the historic reason that they mix JCL with 
an add-on language, and two different add-on languages at that. JES, on 
the other hand, being a standard component from the beginning, relied 
on existing JCL and new additions to JCL.

-- 
John W Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
  -- Charles Williams.  "Judgement at Chelmsford"

0
John
10/18/2013 11:07:50 PM
On 2013-10-18 18:31:11 +0000, glen herrmannsfeldt said:

> robin.vowels@gmail.com wrote:
> 
> (snip)
> 
>> I'm a bit [no pun intended] puzzled about this 6-bit thing.
>> It's not exactly a convenient size, like 6 into 32 doesn't go.
>> The nature of the machine is 8-bit characters, not 6-bit.
>> So the natural thought is for 8-bit characters for each of the tokens
>> that are special characters, with some more reserved for composite
>> characters stored as an 8-bit quantity.
> 
> SIXBIT is used by DEC 36 bit systems, which store six characters
> from half the ASCII set in a 36 bit word. That is, for example, used
> by file names in directories, and also for symbolic names in
> assemblers and compilers (and object programs).
> 
> ASCII text on 36 bit systems is five characters per word.
> 
> PDP-11 systems use Radix 50 to store a smaller ASCII subset,
> three characters in a 16 bit word, for similar purposes.

The old Infocom games ("Zork", "Hitchhiker's Guide to the Galaxy", 
etc.) held text as three five-bit characters (with shifting) in a 
16-bit word.

-- 
John W Kennedy
"...when you're trying to build a house of cards, the last thing you 
should do is blow hard and wave your hands like a madman."
  --  Rupert Goodwins

0
John
10/18/2013 11:12:40 PM
On 2013-10-18 22:40:48 +0000, James J. Weinkam said:
> Although the PL/I language is supposed to be machine independent, the F 
> compiler ran on the IBM 360 and its equivalents and successors. The 360 
> could store character data either in EBCDIC or ASCII-8. There was a PSW 
> bit that specified which. I never encountered an installation that used 
> anything but EBCDIC. I don't know if the F compiler worked with the 
> ASCII bit set or not.

ASCII-8 became a lost cause when the ASCII punched card was abandoned. 
No released operating system ever supported the ASCII PSW bit, and no 
other hardware ever supported ASCII-8 except the modem-attached version 
of the 2260 series (forerunner of the 3270).

> With PC implementations, source code is written using the 60 character 
> set with the addition of the 26 lower case letters stored internally 
> using ASCII-8.

That's 8-bit "extended ASCII", which is not at all the same thing as 
the abandoned ASCII-8 code proposed for the 360.

-- 
John W Kennedy
Read the remains of Shakespeare's lost play, now annotated!
http://www.SKenSoftware.com/Double%20Falshood

0
John
10/18/2013 11:28:53 PM
John W Kennedy wrote:
>
> The obvious PL/I translation is not, because all PL/I declarations in a block "happen" at the same time.
>
> foo: procedure options (main);
> declare i fixed binary initial (1);
> declare j fixed binary initial (i + 1); /* Wrong! */
> put list (j); put skip;
> end;
>
> But since this is talking about a feature that PL/I /doesn't/ have, it's of marginal relevance.
>
Your example is almost perfectly legal PL/I. The only problem is that the initial expression needs to be parenthesized.

PL/I allows the use of expressions for various components of declare statements such as array bounds, string lengths, 
area sizes, arithmetic precision, and initial values. In cases where the value must be known at compile time such as 
precisions or any of the others for static storage the expression must be a restricted expression. PL/I also allows 
variable declarations to be expressed one per declare statement or several per statement, and for the declarations to be 
arranged in any order within a statement and for the statements to be placed in any order anywhere within the block. 
None of this has any effect on the meaning of the declarations. Finally, it allows  expressions in a declare statement 
to depend on each other as long as the dependency graph is acyclic. At least the optimizer did all this; possibly it 
went beyond the language definition. Given that the dependency graph is acyclic, it defines a partial order on the 
various elements involved which can be extended to a linear order. Therefore consistent elaboration is always possible.

At least some work station compilers require that the dependent declarations actually appear in such a linear order. 
Personal PL/I for OS/2 is one such. I had to rearrange some declare statements to get a couple of my old optimizer 
programs to work.
0
James
10/18/2013 11:46:31 PM
On 10/18/2013 3:12 PM, glen herrmannsfeldt wrote:
> Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
>> In <l3nl4c$tup$1@speranza.aioe.org>, on 10/17/2013
>>    at 03:21 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
>
>>> I also remember being confused by CMS, where EXEC2 and EXEC3
>
>> I know EXEC, EXEC2 and REXX, but WTF is EXEC3? Or is this a case where
>> I'll wish I didn't know?
>
> Oh, yes, off by one.
>
> Now, why is it that there is JES2 and JES3, but no JES1?

Apparently there actually was a JES1, which was JES for OS/VS1.  I hjad 
never heard of this wither until a little while ago.


-- 
Pete
0
Peter
10/18/2013 11:53:26 PM
On 10/18/2013 3:18 PM, Shmuel (Seymour J.) Metz wrote:
> In <l3pbuv$guu$2@dont-email.me>, on 10/17/2013
>     at 03:02 PM, Peter Flass <Peter_Flass@Yahoo.com> said:
>
>> I agree.  I always now try to stick to 80 (having abandoned the
>> 2-72 convention some time ago).
>
> Sequence numbers are convenient..

Only if you're using a system and an editor that supports them.

>
>> Too long a line can be difficult to read.
>
> Indeed; even after I started using RECFM=VB for PL/I, I kept most of
> my code well below LRECL due to readability considerations.
>


-- 
Pete
0
Peter
10/18/2013 11:55:20 PM
John W Kennedy <jwkenne@attglobal.net> wrote:

(snip, I wrote)
>> PDP-11 systems use Radix 50 to store a smaller ASCII subset,
>> three characters in a 16 bit word, for similar purposes.
 
> The old Infocom games ("Zork", "Hitchhiker's Guide to the Galaxy", 
> etc.) held text as three five-bit characters (with shifting) in a 
> 16-bit word.

That wouldn't be enough for file names and program identifiers.
You need at least 36 (letters and numbers) different characters.
The DEC Radix 50 is actual base 40, as the 50 is octal.
Letters, digits, space, period, and two others that I forget.

And the IBM 36 bit machines used a code called BCD, or sometimes
BCDIC, the reason why Fortran allowed only six character names.

-- glen
0
glen
10/19/2013 1:22:50 AM
James J. Weinkam <jjw@cs.sfu.ca> wrote:
> Peter Flass wrote:
(snip)
>> Except them.

> You are confusing the subset of characters used to write 
> language statements and the internal encoding of character data.
> 
> As I recall, the F compiler had two possible external encodings 
> for source input: BCD (64 characters, 63 if coming from 7-track 
> even parity tape) and EBCDIC (256 characters). Regardless of 
> the external encoding, the internal encoding was the host 
> machine's character encoding. 

I am not so sure about tape, but programs would accept the punched
card codes from BCD programs. 

The IBM computers before the 360 used different codes for the 
scientific and commercial computers. With EBCDIC, there were enough
go give each a unique code point, but they weren't unique on cards
(or, I believe, 7 track tape). As far as I know, the BCD mode is
for punched card codes.

For example, the '+' was the 12 punch on scientific machines, 
and the '&' on commercial machines. It went to '&' in BCD.

> Although the PL/I language is supposed to be machine independent, 
> the F compiler ran on the IBM 360 and its equivalents and 
> successors. The 360 could store character data either in EBCDIC 
> or ASCII-8. There was a PSW bit that specified which. 
> I never encountered an installation that used anything but 
> EBCDIC. I don't know if the F compiler worked with the ASCII 
> bit set or not.

There weren't any. The bit could only be turned on by the OS,
and no IBM OS had the ability to do it. (I suppose CP/67 could.)

At the time the 360 was designed, there was a proposed ASCII-8 code.
(It isn't ASCII-7 with an additional bit.) The standard never
appeared, so there was no need for it. 

But even so, the bit doesn't change the character set that 
people would use, but it does change the signs and zones used
by the decimal instructions and UNPK. But it isn't that hard to
use XC to fix up the zones if needed, which is probably what
anyone did who needed it. (For example, for RECFM=D tapes.)

> Independent of the encoding used to input source programs and 
> how the characters, once read, are encoded internally is 
> the subset of the available characters used to express source 
> programs (other than character constants and comments). 
> Here there were two choices: the 60 character set and the 48 
> character set. The 48 character set consisted of 26 
> letters, 10 digits, blank, and eleven special 
> characters: + - * / ( ) = . , ' $ Other "characters" essential 
> to express the language were composite: AND OR CAT GT LT GE etc. 
> Most require special spacing rules to render them unambiguous ..  
> represented the colon, ,. the semi colon etc. Even the 60 
> character set with twelve additional special characters needs 
> quite a few composite symbols: ** || -> >= <= etc.
 
> The reason for having the 48 character set was to facilitate 
> input preparation on 024 and 026 keypunches and to accommodate 
> old unit record printers (403s and 407s) that only had 48 
> printable characters. To make matters worse, most installations 
> had printers for which the codes for + ( ) and ' printed 
> as & % losenge and @. Reading such printouts was not for the 
> faint of heart.

Some may have run the 48 character trains on the 1403, too.
None that I knew, but the 1403 would print faster with such
trains if you were doing Fortran or other languages with only
the 48 character set.

I believe for the (F) compiler if you specify the 48 character
set it does a preprocessor pass that converts the input, and
then runs the 60 character compiler. 
 
> Even now PL/I still basically uses the 60 character set to 
> express programs. The 26 lower case letters are allowed but 
> are essentially equivalent to their corresponding upper case 
> versions. There are also a few options to accommodate foreign 
> language characters and currency symbols.

PL/I allows for @, #, and $ as letters, as those positions are
letters in some other alphabets.
 
> With PC implementations, source code is written using the 60 
> character set with the addition of the 26 lower case 
> letters stored internally using ASCII-8.

More likely ASCII-7.   As far as I know, there are no programs
using the ASCII-8 code.

-- glen

0
glen
10/19/2013 1:42:57 AM
John W Kennedy <jwkenne@attglobal.net> wrote:

(snip, I wrote)
>> Now, why is it that there is JES2 and JES3, but no JES1?
 
> I don't know how far you go back, but when IBM announced virtual memory 
> for the 370, it announced two successor products to OS/360: OS/VS1, 
> based on OS/360 MFT, and OS/VS2, based on OS/360 MVT. (Sometimes the 
> two were collectively known as OS/VS, but they were always two 
> different products.) 

I remember the transition from MVT to OS/VS2, but don't remember
knowing any systems running OS/VS1.

The system I used at the time had one machine running MVT, 
two running OS/VS2 and all spooled through ASP.

> OS/VS1 had a SPOOLing system named "JES". It was 
> only later, when OS/VS2 was split into SVS (a new name for the original 
> OS/VS2) and MVS (a new version) that the old add-on products HASP and 
> ASP were renamed JES2 and JES3, and made standard parts of the system.

I knew the result, but not  how it happened. 

 
> OS/360: SAM SPOOLing, optionally replaced by HASP or ASP

HASP on the ones I knew, until the ASP system described above.
 
> OS/VS1: JES
 
> OS/VS2 1.x (later known as SVS): SAM SPOOLing, optionally replaced by 
> HASP or ASP
 
> OS/VS2 2.0 and up (MVS): JES2 (based on HASP) or JES3 (based on ASP)
 
> Sometimes JES has been called "JES1", but never officially
 
> The fact that HASP and ASP were add-on programs, and two different 
> add-on programs at that, are the historic reason that they mix JCL with 
> an add-on language, and two different add-on languages at that. JES, on 
> the other hand, being a standard component from the beginning, relied 
> on existing JCL and new additions to JCL.

Yes, I remember the transition from HASP to ASP, new control cards,
including ones to select which system your job ran on.

-- glen
 
0
glen
10/19/2013 1:50:14 AM
On 2013-10-18 23:46:31 +0000, James J. Weinkam said:

> John W Kennedy wrote:
>> 
>> The obvious PL/I translation is not, because all PL/I declarations in a 
>> block "happen" at the same time.
>> 
>> foo: procedure options (main);
>> declare i fixed binary initial (1);
>> declare j fixed binary initial (i + 1); /* Wrong! */
>> put list (j); put skip;
>> end;
>> 
>> But since this is talking about a feature that PL/I /doesn't/ have, 
>> it's of marginal relevance.
>> 
> Your example is almost perfectly legal PL/I. The only problem is that 
> the initial expression needs to be parenthesized.
> 
> PL/I allows the use of expressions for various components of declare 
> statements such as array bounds, string lengths, area sizes, arithmetic 
> precision, and initial values. In cases where the value must be known 
> at compile time such as precisions or any of the others for static 
> storage the expression must be a restricted expression. PL/I also 
> allows variable declarations to be expressed one per declare statement 
> or several per statement, and for the declarations to be arranged in 
> any order within a statement and for the statements to be placed in any 
> order anywhere within the block. None of this has any effect on the 
> meaning of the declarations. Finally, it allows  expressions in a 
> declare statement to depend on each other as long as the dependency 
> graph is acyclic. At least the optimizer did all this; possibly it went 
> beyond the language definition. Given that the dependency graph is 
> acyclic, it defines a partial order on the various elements involved 
> which can be extended to a linear order. Therefore consistent 
> elaboration is always possible.
> 
> At least some work station compilers require that the dependent 
> declarations actually appear in such a linear order. Personal PL/I for 
> OS/2 is one such. I had to rearrange some declare statements to get a 
> couple of my old optimizer programs to work.

The old Language Specification Manual and the (F) Language Reference do 
indeed allow for such definitions, but the Enterprise PL/I Language 
Reference and the 2.3.0 Language Reference agree with me. I can't find 
a Personal manual.

-- 
John W Kennedy
Read the remains of Shakespeare's lost play, now annotated!
http://www.SKenSoftware.com/Double%20Falshood

0
John
10/19/2013 4:24:44 AM
On Saturday, October 19, 2013 9:40:48 AM UTC+11, James J. Weinkam wrote:
> Peter Flass wrote: > On 10/17/2013 11:09 PM, nospam@gmail.com wrote:
>> On Friday, October 18, 2013 6:07:48 AM UTC+11, Peter Flass wrote:=20
>>> (F) stored all text internally in sixbit encoding.=20

>> >> What about character constants?

> > Except them.

> You are confusing the subset of characters used to write language stateme=
nts and the internal encoding of character data. As I recall, the F compile=
r had two possible external encodings for source input: BCD (64 characters,=
 63 if coming from 7-track even parity tape) and EBCDIC (256 characters).

Input from 5-channel paper tape was another that we used.
0
robin
10/19/2013 5:20:08 AM
On Saturday, October 19, 2013 9:40:48 AM UTC+11, James J. Weinkam wrote:

> Even now PL/I still basically uses the 60 character set to express programs.

That's al that\s availabnle, as there is no longer provision for the
48-character set.

> The 26 lower case letters are allowed but are essentially equivalent to their corresponding upper case versions. There are also a few options to accommodate foreign language characters and currency symbols.

The characters @ $ and # may be used in foreign language keyboards for
other lingual characters as letters (for identifiers).

> With PC implementations, source code is written using the 60 character
> set with the addition of the 26 lower case letters stored internally using
> ASCII-8.

0
robin
10/19/2013 5:26:51 AM
On Saturday, October 19, 2013 5:17:27 AM UTC+11, Seymour J. Shmuel Metz wrote: > In <l3p....@dont-email.me>, on 10/17/2013 at 03:02 PM, Peter Flass <P....@Yahoo.com> said:
>>I agree. I always now try to stick to 80 (having abandoned the
>>2-72 convention some time ago). 

> Sequence numbers are convenient.

What? In case you drop your VDU?

> Too long a line can be difficult to read.

80 is too short, particularly when the nesting level is deep.
120 is a reasonable length in such cases.

 > Indeed; even after I started using RECFM=VB for PL/I,
> I kept most of my code well below LRECL due to readability considerations.

The compiler listing could deliver quite long lines.
0
robin
10/19/2013 5:38:12 AM
On Saturday, October 19, 2013 9:40:48 AM UTC+11, James J. Weinkam wrote:

> Even now PL/I still basically uses the 60 character set to express progra=
ms. The 26 lower case letters are allowed but are essentially equivalent to=
 their corresponding upper case versions. There are also a few options to a=
ccommodate foreign language characters and currency symbols. With PC implem=
entations, source code is written using the 60 character set with the addit=
ion of the 26 lower case letters stored internally using ASCII-8.

Any of the 256 characters can be used in character constants --
including upper and lower-chase characters.

0
robin
10/19/2013 5:40:38 AM
On Saturday, October 19, 2013 12:42:57 PM UTC+11, glen herrmannsfeldt wrote:

> I believe for the (F) compiler if you specify the 48 character set it does
> a preprocessor pass that converts the input,

The F-compiler converted the source internally.  The printed form
a la compiler listing was in the original form (48-character set).
0
robin
10/19/2013 5:50:18 AM
On 19/10/2013 06:38, robin.vowels@gmail.com wrote:
> On Saturday, October 19, 2013 5:17:27 AM UTC+11, Seymour J. Shmuel Metz wrote: > In <l3p....@dont-email.me>, on 10/17/2013 at 03:02 PM, Peter Flass <P....@Yahoo.com> said:
>>> I agree. I always now try to stick to 80 (having abandoned the
>>> 2-72 convention some time ago).
>
>> Sequence numbers are convenient.
>
> What? In case you drop your VDU?
>
>> Too long a line can be difficult to read.
>
> 80 is too short, particularly when the nesting level is deep.
> 120 is a reasonable length in such cases.
>
>   > Indeed; even after I started using RECFM=VB for PL/I,
>> I kept most of my code well below LRECL due to readability considerations.
>
> The compiler listing could deliver quite long lines.
>
I work with a line length that conveniently fits in the editor window. 
Having said that, I find that 80 is sometimes too short a line but not 
very often. I would set a slightly longer value as an absolute maximum 
reasonable line length, 90 perhaps? It still has to fit on the width of 
an A4 sheet in a reasonabe size of font. (Yes, I do print source sometimes).

The point I wanted to make however is that the program nesting level 
should not be so deep that the code starts to drift off the right hand 
side of the screen. It is not a very readable arrangement. (Well ok, I 
do it sometimes, but I don't like it).
0
Peter
10/19/2013 9:38:48 AM
On 19/10/2013 02:50, glen herrmannsfeldt wrote:
> John W Kennedy <jwkenne@attglobal.net> wrote:
>
> (snip, I wrote)
>>> Now, why is it that there is JES2 and JES3, but no JES1?
>
>> I don't know how far you go back, but when IBM announced virtual memory
>> for the 370, it announced two successor products to OS/360: OS/VS1,
>> based on OS/360 MFT, and OS/VS2, based on OS/360 MVT. (Sometimes the
>> two were collectively known as OS/VS, but they were always two
>> different products.)
>
> I remember the transition from MVT to OS/VS2, but don't remember
> knowing any systems running OS/VS1.
>
......

I the 1970s I worked at a site that migrated from DOS/VS (with POWER) to 
OS/VS1 (with a variety of JES).

0
Peter
10/19/2013 9:48:09 AM
On 10/18/2013 7:46 PM, James J. Weinkam wrote:
> John W Kennedy wrote:
>>
>> The obvious PL/I translation is not, because all PL/I declarations in
>> a block "happen" at the same time.
>>
>> foo: procedure options (main);
>> declare i fixed binary initial (1);
>> declare j fixed binary initial (i + 1); /* Wrong! */
>> put list (j); put skip;
>> end;
>>
>> But since this is talking about a feature that PL/I /doesn't/ have,
>> it's of marginal relevance.
>>
> Your example is almost perfectly legal PL/I. The only problem is that
> the initial expression needs to be parenthesized.

Good catch!


> Finally, it allows  expressions in a
> declare statement to depend on each other as long as the dependency
> graph is acyclic. At least the optimizer did all this; possibly it went
> beyond the language definition. Given that the dependency graph is
> acyclic, it defines a partial order on the various elements involved
> which can be extended to a linear order. Therefore consistent
> elaboration is always possible.

I think this isn't specified.  I'd have to check the standard if anyone 
is really interested.  I have always tried to imbed the dependent 
declarations in a BEGIN-block so that the depended-on declarations are 
always guaranteed to be done first.

>
> At least some work station compilers require that the dependent
> declarations actually appear in such a linear order. Personal PL/I for
> OS/2 is one such. I had to rearrange some declare statements to get a
> couple of my old optimizer programs to work.

Iron Spring PL/I does this.  Like I said, I think the results are 
"undefined."


-- 
Pete
0
Peter
10/19/2013 12:08:30 PM
On 10/18/2013 9:42 PM, glen herrmannsfeldt wrote:
> > At the time the 360 was designed, there was a proposed ASCII-8 code.
> (It isn't ASCII-7 with an additional bit.) The standard never
> appeared, so there was no need for it.

Is there a reference for this?


-- 
Pete
0
Peter
10/19/2013 12:14:28 PM
On 10/18/2013 9:50 PM, glen herrmannsfeldt wrote:
>
> Yes, I remember the transition from HASP to ASP, new control cards,
> including ones to select which system your job ran on.
>

Once again it's a case of IBMers protecting their turf,  I never could 
figure out why similar functions didn't use similar control cards.  I 
think RJE LOGON and LOGOFF were the only common commands.

-- 
Pete
0
Peter
10/19/2013 12:16:59 PM
On 2013-10-19 05:20:08 +0000, robin.vowels@gmail.com said:

> On Saturday, October 19, 2013 9:40:48 AM UTC+11, James J. Weinkam wrote:
>> Peter Flass wrote: > On 10/17/2013 11:09 PM, nospam@gmail.com wrote:
>>> On Friday, October 18, 2013 6:07:48 AM UTC+11, Peter Flass wrote:>>> 
>>> (F) stored all text internally in sixbit encoding.
>>>>> What about character constants?
> 
>>> Except them.
> 
>> You are confusing the subset of characters used to write language 
>> statements and the internal encoding of character data. As I recall, 
>> the F compiler had two possible external encodings for source input: 
>> BCD (64 characters, 63 if coming from 7-track even parity tape) and 
>> EBCDIC (256 characters).
> 
> Input from 5-channel paper tape was another that we used.

I'm pretty sure QSAM translated 2671 input into EBCDIC. If, on the 
other hand, it was the tape reader on a terminal, then the 
telecommunications software definitely translated it (since it had to 
translate the printer-keyboard anyway).

-- 
John W Kennedy
"Sweet, was Christ crucified to create this chat?"
  -- Charles Williams.  "Judgement at Chelmsford"

0
John
10/19/2013 12:24:41 PM
On 2013-10-19 12:14:28 +0000, Peter Flass said:

> On 10/18/2013 9:42 PM, glen herrmannsfeldt wrote:
>>> At the time the 360 was designed, there was a proposed ASCII-8 code.
>> (It isn't ASCII-7 with an additional bit.) The standard never
>> appeared, so there was no need for it.
> 
> Is there a reference for this?

Any 360 P of Op or (I think) the green card. Basically, the bits of 
regular ASCII were mapped as 65643210, with the results that space 
became 40, just like EBCDIC; the bytes 20, 21, and 22, used by the ED 
and EDMK instructions, were non-ASCII; and the zone nibbles of packed 
decimal were distinguishable from digits.

-- 
John W Kennedy
A proud member of the reality-based community.

0
John
10/19/2013 12:35:25 PM
On 2013-10-19 12:16:59 +0000, Peter Flass said:

> On 10/18/2013 9:50 PM, glen herrmannsfeldt wrote:
>> 
>> Yes, I remember the transition from HASP to ASP, new control cards,
>> including ones to select which system your job ran on.
>> 
> 
> Once again it's a case of IBMers protecting their turf,

No, it was a question of ASP being only vaguely described when HASP 
being created as a skunk-works project for MFT I, ca. 1966-67.

>   I never could figure out why similar functions didn't use similar 
> control cards.  I think RJE LOGON and LOGOFF were the only common 
> commands.


-- 
John W Kennedy
"I want everybody to be smart. As smart as they can be. A world of 
ignorant people is too dangerous to live in."
  -- Garson Kanin. "Born Yesterday"

0
John
10/19/2013 12:37:26 PM
Peter Flass <Peter_Flass@yahoo.com> wrote:
> On 10/18/2013 9:42 PM, glen herrmannsfeldt wrote:
>> > At the time the 360 was designed, there was a proposed ASCII-8 code.
>> (It isn't ASCII-7 with an additional bit.) The standard never
>> appeared, so there was no need for it.
 
> Is there a reference for this?

I believe it is in Blaauw & Brooks, "Computer Architecture: Concepts
and Evolution."

It is a good reference for computer architecture in general, but
they have especially detailed discussion on S/360 and S/370.

The actual ASCII-8 table is in the "S/360 Principles of Operation."

-- glen
0
glen
10/19/2013 1:45:42 PM
John W Kennedy wrote:
> On 2013-10-18 23:46:31 +0000, James J. Weinkam said:
>
>> John W Kennedy wrote:
>>>
>>> The obvious PL/I translation is not, because all PL/I declarations in a block "happen" at the same time.
>>>
>>> foo: procedure options (main);
>>> declare i fixed binary initial (1);
>>> declare j fixed binary initial (i + 1); /* Wrong! */
>>> put list (j); put skip;
>>> end;
>>>
>>> But since this is talking about a feature that PL/I /doesn't/ have, it's of marginal relevance.
>>>
>> Your example is almost perfectly legal PL/I. The only problem is that the initial expression needs to be parenthesized.
>>
>> PL/I allows the use of expressions for various components of declare statements such as array bounds, string lengths,
>> area sizes, arithmetic precision, and initial values. In cases where the value must be known at compile time such as
>> precisions or any of the others for static storage the expression must be a restricted expression. PL/I also allows
>> variable declarations to be expressed one per declare statement or several per statement, and for the declarations to
>> be arranged in any order within a statement and for the statements to be placed in any order anywhere within the
>> block. None of this has any effect on the meaning of the declarations. Finally, it allows expressions in a declare
>> statement to depend on each other as long as the dependency graph is acyclic. At least the optimizer did all this;
>> possibly it went beyond the language definition. Given that the dependency graph is acyclic, it defines a partial
>> order on the various elements involved which can be extended to a linear order. Therefore consistent elaboration is
>> always possible.
>>
>> At least some work station compilers require that the dependent declarations actually appear in such a linear order.
>> Personal PL/I for OS/2 is one such. I had to rearrange some declare statements to get a couple of my old optimizer
>> programs to work.
>
> The old Language Specification Manual and the (F) Language Reference do indeed allow for such definitions, but the
> Enterprise PL/I Language Reference and the 2.3.0 Language Reference agree with me. I can't find a Personal manual.
>
You are right. The Language Specs and the F reference manual only require the dependency graph to be acyclic. The 
Optimizer reference manual limits the path length in the dependency graph to 1. The reference manuals for later 
implementations forbid dependency altogether. Each new implementation waters it down more. I had never noticed that. 
Nevertheless, at least in Personal PL/I dependencies work if each declarations appears after any items it depends on. I 
doubt that I ever used more than one level of dependency.

Here is a more elaborate example using Personal PL/I for OS/2.

% process mar(2,100) offset libs(multi); /* test */
  test: proc options(main) reorder;
   dcl
    (i init(1),j init((i+1)),k init((j+1)),m init((i+j+k))) bin fixed,
    sysprint file print;
   put file(sysprint) edit(i,j,k,m)(col(1),4 f(4));
   end test;

5639-C96 IBM Personal PL/I for OS/2          V1.R2.37   2013.10.19  14:37:32
Copyright (C) IBM Corporation 1992,1997
Licensed Material - Property of IBM. All rights reserved.

File Reference Table

   File    Included From  Name

      1                   E:\PLI\test327.pli

Component    Return Code    Messages (Total/Suppressed)    Time

Compiler         0                0  /  0                   0 secs

End of compilation of TEST

IBM(R) Linker for OS/2(R), Version 01.02.03
(C) Copyright IBM Corporation 1988, 1995.
(C) Copyright Microsoft Corp. 1988, 1989.
  - Licensed Material - Program-Property of IBM - All Rights Reserved.

ILink : warning LNK4071: application type not specified; assuming WINDOWCOMPAT
    1   2   3   6
0
James
10/19/2013 10:15:56 PM
On Sunday, October 20, 2013 9:15:56 AM UTC+11, James J. Weinkam wrote:
> John W Kennedy wrote: > On 2013-10-18 23:46:31 +0000, James J. Weinkam sa=
id: > >> John W Kennedy wrote: >>> >>> The obvious PL/I translation is not,=
 because all PL/I declarations in a block "happen" at the same time. >>> >>=
> foo: procedure options (main); >>> declare i fixed binary initial (1); >>=
> declare j fixed binary initial (i + 1); /* Wrong! */ >>> put list (j); pu=
t skip; >>> end; >>> >>> But since this is talking about a feature that PL/=
I /doesn't/ have, it's of marginal relevance. >>> >> Your example is almost=
 perfectly legal PL/I. The only problem is that the initial expression need=
s to be parenthesized. >> >> PL/I allows the use of expressions for various=
 components of declare statements such as array bounds, string lengths, >> =
area sizes, arithmetic precision, and initial values. In cases where the va=
lue must be known at compile time such as >> precisions or any of the other=
s for static storage the expression must be a restricted expression. PL/I a=
lso allows >> variable declarations to be expressed one per declare stateme=
nt or several per statement, and for the declarations to >> be arranged in =
any order within a statement and for the statements to be placed in any ord=
er anywhere within the >> block. None of this has any effect on the meaning=
 of the declarations. Finally, it allows expressions in a declare >> statem=
ent to depend on each other as long as the dependency graph is acyclic. At =
least the optimizer did all this; >> possibly it went beyond the language d=
efinition. Given that the dependency graph is acyclic, it defines a partial=
 >> order on the various elements involved which can be extended to a linea=
r order. Therefore consistent elaboration is >> always possible. >> >> At l=
east some work station compilers require that the dependent declarations ac=
tually appear in such a linear order. >> Personal PL/I for OS/2 is one such=
.. I had to rearrange some declare statements to get a couple of my old opti=
mizer >> programs to work. > > The old Language Specification Manual and th=
e (F) Language Reference do indeed allow for such definitions, but the > En=
terprise PL/I Language Reference and the 2.3.0 Language Reference agree wit=
h me. I can't find a Personal manual. > You are right. The Language Specs a=
nd the F reference manual only require the dependency graph to be acyclic. =
The Optimizer reference manual limits the path length in the dependency gra=
ph to 1. The reference manuals for later implementations forbid dependency =
altogether. Each new implementation waters it down more. I had never notice=
d that. Nevertheless, at least in Personal PL/I dependencies work if each d=
eclarations appears after any items it depends on. I doubt that I ever used=
 more than one level of dependency. Here is a more elaborate example using =
Personal PL/I for OS/2. % process mar(2,100) offset libs(multi); /* test */=
 test: proc options(main) reorder; dcl (i init(1),j init((i+1)),k init((j+1=
)),m init((i+j+k))) bin fixed, sysprint file print; put file(sysprint) edit=
(i,j,k,m)(col(1),4 f(4)); end test; 5639-C96 IBM Personal PL/I for OS/2 V1.=
R2.37 2013.10.19 14:37:32 Copyright (C) IBM Corporation 1992,1997 Licensed =
Material - Property of IBM. All rights reserved. File Reference Table File =
Included From Name 1 E:\PLI\test327.pli Component Return Code Messages (Tot=
al/Suppressed) Time Compiler 0 0 / 0 0 secs End of compilation of TEST IBM(=
R) Linker for OS/2(R), Version 01.02.03 (C) Copyright IBM Corporation 1988,=
 1995. (C) Copyright Microsoft Corp. 1988, 1989. - Licensed Material - Prog=
ram-Property of IBM - All Rights Reserved. ILink : warning LNK4071: applica=
tion type not specified; assuming WINDOWCOMPAT 1 2 3 6

Wasn't the VALUE intended to cover this?
0
robin
10/19/2013 11:15:17 PM
On 2013-10-19 23:15:17 +0000, robin.vowels@gmail.com said:

> On Sunday, October 20, 2013 9:15:56 AM UTC+11, James J. Weinkam wrote:
>> John W Kennedy wrote: > On 2013-10-18 23:46:31 +0000, James J. Weinkam 
>> said: > >> John W Kennedy wrote: >>> >>> The obvious PL/I translation 
>> is not, because all PL/I declarations in a block "happen" at the same 
>> time. >>> >>> foo: procedure options (main); >>> declare i fixed binary 
>> initial (1); >>> declare j fixed binary initial (i + 1); /* Wrong! */ 
>> >>> put list (j); put skip; >>> end; >>> >>> But since this is talking 
>> about a feature that PL/I /doesn't/ have, it's of marginal relevance. 
>> >>> >> Your example is almost perfectly legal PL/I. The only problem is 
>> that the initial expression needs to be parenthesized. >> >> PL/I 
>> allows the use of expressions for various components of declare 
>> statements such as array bounds, string lengths, >> area sizes, 
>> arithmetic precision, and initial values. In cases where the value must 
>> be known at compile time such as >> precisions or any of the others for 
>> static storage the expression must be a restricted expression. PL/I 
>> also allows >> variable declarations to be expressed one per declare 
>> statement or several per statement, and for the declarations to >> be 
>> arranged in any order within a statement and for the statements to be 
>> placed in any order anywhere within the >> block. None of this has any 
>> effect on the meaning of the declarations. Finally, it allows 
>> expressions in a declare >> statement to depend on each other as long 
>> as the dependency graph is acyclic. At least the optimizer did all 
>> this; >> possibly it went beyond the language definition. Given that 
>> the dependency graph is acyclic, it defines a partial >> order on the 
>> various elements involved which can be extended to a linear order. 
>> Therefore consistent elaboration is >> always possible. >> >> At least 
>> some work station compilers require that the dependent declarations 
>> actually appear in such a linear order. >> Personal PL/I for OS/2 is 
>> one such. I had to rearrange some declare statements to get a couple of 
>> my old optimizer >> programs to work. > > The old Language 
>> Specification Manual and the (F) Language Reference do indeed allow for 
>> such definitions, but the > Enterprise PL/I Language Reference and the 
>> 2.3.0 Language Reference agree with me. I can't find a Personal manual. 
>> > You are right. The Language Specs and the F reference manual only 
>> require the dependency graph to be acyclic. The Optimizer reference 
>> manual limits the path length in the dependency graph to 1. The 
>> reference manuals for later implementations forbid dependency 
>> altogether. Each new implementation waters it down more. I had never 
>> noticed that. Nevertheless, at least in Personal PL/I dependencies work 
>> if each declarations appears after any items it depends on. I doubt 
>> that I ever used more than one level of dependency. Here is a more 
>> elaborate example using Personal PL/I for OS/2. % process mar(2,100) 
>> offset libs(multi); /* test */ test: proc options(main) reorder; dcl (i 
>> init(1),j init((i+1)),k init((j+1)),m init((i+j+k))) bin fixed, 
>> sysprint file print; put file(sysprint) edit(i,j,k,m)(col(1),4 f(4)); 
>> end test; 5639-C96 IBM Personal PL/I for OS/2 V1.R2.37 2013.10.19 
>> 14:37:32 Copyright (C) IBM Corporation 1992,1997 Licensed Material - 
>> Property of IBM. All rights reserved. File Reference Table File 
>> Included From Name 1 E:\PLI\test327.pli Component Return Code Messages 
>> (Total/Suppressed) Time Compiler 0 0 / 0 0 secs End of compilation of 
>> TEST IBM(R) Linker for OS/2(R), Version 01.02.03 (C) Copyright IBM 
>> Corporation 1988, 1995. (C) Copyright Microsoft Corp. 1988, 1989. - 
>> Licensed Material - Program-Property of IBM - All Rights Reserved. 
>> ILink : warning LNK4071: application type not specified; assuming 
>> WINDOWCOMPAT 1 2 3 6
> 
> Wasn't the VALUE intended to cover this?

Certain problems with INITIAL can be solved by using VALUE instead, but 
not all. The point of VALUE is to create named constants (as opposed to 
variables that don't happen to be updated).

-- 
John W Kennedy
"The grand art mastered the thudding hammer of Thor
And the heart of our lord Taliessin determined the war."
  -- Charles Williams.  "Mount Badon"

0
John
10/20/2013 12:03:52 AM
On Sunday, October 20, 2013 11:03:52 AM UTC+11, John W Kennedy wrote:
> On 2013-10-19 23:15:17 +0000, nospam@gmail.com said: > On Sunday, October=
 20, 2013 9:15:56 AM UTC+11, James J. Weinkam wrote: >> John W Kennedy wrot=
e: > On 2013-10-18 23:46:31 +0000, James J. Weinkam >> said: > >> John W Ke=
nnedy wrote: >>> >>> The obvious PL/I translation >> is not, because all PL=
/I declarations in a block "happen" at the same >> time. >>> >>> foo: proce=
dure options (main); >>> declare i fixed binary >> initial (1); >>> declare=
 j fixed binary initial (i + 1); /* Wrong! */ >> >>> put list (j); put skip=
; >>> end; >>> >>> But since this is talking >> about a feature that PL/I /=
doesn't/ have, it's of marginal relevance. >> >>> >> Your example is almost=
 perfectly legal PL/I. The only problem is >> that the initial expression n=
eeds to be parenthesized. >> >> PL/I >> allows the use of expressions for v=
arious components of declare >> statements such as array bounds, string len=
gths, >> area sizes, >> arithmetic precision, and initial values. In cases =
where the value must >> be known at compile time such as >> precisions or a=
ny of the others for >> static storage the expression must be a restricted =
expression. PL/I >> also allows >> variable declarations to be expressed on=
e per declare >> statement or several per statement, and for the declaratio=
ns to >> be >> arranged in any order within a statement and for the stateme=
nts to be >> placed in any order anywhere within the >> block. None of this=
 has any >> effect on the meaning of the declarations. Finally, it allows >=
> expressions in a declare >> statement to depend on each other as long >> =
as the dependency graph is acyclic. At least the optimizer did all >> this;=
 >> possibly it went beyond the language definition. Given that >> the depe=
ndency graph is acyclic, it defines a partial >> order on the >> various el=
ements involved which can be extended to a linear order. >> Therefore consi=
stent elaboration is >> always possible. >> >> At least >> some work statio=
n compilers require that the dependent declarations >> actually appear in s=
uch a linear order. >> Personal PL/I for OS/2 is >> one such. I had to rear=
range some declare statements to get a couple of >> my old optimizer >> pro=
grams to work. > > The old Language >> Specification Manual and the (F) Lan=
guage Reference do indeed allow for >> such definitions, but the > Enterpri=
se PL/I Language Reference and the >> 2.3.0 Language Reference agree with m=
e. I can't find a Personal manual. >> > You are right. The Language Specs a=
nd the F reference manual only >> require the dependency graph to be acycli=
c. The Optimizer reference >> manual limits the path length in the dependen=
cy graph to 1. The >> reference manuals for later implementations forbid de=
pendency >> altogether. Each new implementation waters it down more. I had =
never >> noticed that. Nevertheless, at least in Personal PL/I dependencies=
 work >> if each declarations appears after any items it depends on. I doub=
t >> that I ever used more than one level of dependency. Here is a more >> =
elaborate example using Personal PL/I for OS/2. % process mar(2,100) >> off=
set libs(multi); /* test */ test: proc options(main) reorder; dcl (i >> ini=
t(1),j init((i+1)),k init((j+1)),m init((i+j+k))) bin fixed, >> sysprint fi=
le print; put file(sysprint) edit(i,j,k,m)(col(1),4 f(4)); >> end test; 563=
9-C96 IBM Personal PL/I for OS/2 V1.R2.37 2013.10.19 >> 14:37:32 Copyright =
(C) IBM Corporation 1992,1997 Licensed Material - >> Property of IBM. All r=
ights reserved. File Reference Table File >> Included From Name 1 E:\PLI\te=
st327.pli Component Return Code Messages >> (Total/Suppressed) Time Compile=
r 0 0 / 0 0 secs End of compilation of >> TEST IBM(R) Linker for OS/2(R), V=
ersion 01.02.03 (C) Copyright IBM >> Corporation 1988, 1995. (C) Copyright =
Microsoft Corp. 1988, 1989. -=20
>> Licensed Material - Program-Property of IBM - All Rights Reserved.=20
>> ILink : warning LNK4071: application type not specified; assuming=20
>> WINDOWCOMPAT 1 2 3 6=20
> > Wasn't the VALUE intended to cover this?

> Certain problems with INITIAL can be solved by using VALUE instead,
> but not all. The point of VALUE is to create named constants
> (as opposed to variables that don't happen to be updated).

The prime point of VALUE was to simplify the recognition of
restricted expressions.
0
robin
10/20/2013 7:43:39 AM
On 2013-10-20 07:43:39 +0000, robin.vowels@gmail.com said:

> On Sunday, October 20, 2013 11:03:52 AM UTC+11, John W Kennedy wrote:
>> On 2013-10-19 23:15:17 +0000, nospam@gmail.com said: > On Sunday, 
>> October 20, 2013 9:15:56 AM UTC+11, James J. Weinkam wrote: >> John W 
>> Kennedy wrote: > On 2013-10-18 23:46:31 +0000, James J. Weinkam >> 
>> said: > >> John W Kennedy wrote: >>> >>> The obvious PL/I translation 
>> >> is not, because all PL/I declarations in a block "happen" at the 
>> same >> time. >>> >>> foo: procedure options (main); >>> declare i 
>> fixed binary >> initial (1); >>> declare j fixed binary initial (i + 
>> 1); /* Wrong! */ >> >>> put list (j); put skip; >>> end; >>> >>> But 
>> since this is talking >> about a feature that PL/I /doesn't/ have, it's 
>> of marginal relevance. >> >>> >> Your example is almost perfectly legal 
>> PL/I. The only problem is >> that the initial expression needs to be 
>> parenthesized. >> >> PL/I >> allows the use of expressions for various 
>> components of declare >> statements such as array bounds, string 
>> lengths, >> area sizes, >> arithmetic precision, and initial values. In 
>> cases where the value must >> be known at compile time such as >> 
>> precisions or any of the others for >> static storage the expression 
>> must be a restricted expression. PL/I >> also allows >> variable 
>> declarations to be expressed one per declare >> statement or several 
>> per statement, and for the declarations to >> be >> arranged in any 
>> order within a statement and for the statements to be >> placed in any 
>> order anywhere within the >> block. None of this has any >> effect on 
>> the meaning of the declarations. Finally, it allows >> expressions in a 
>> declare >> statement to depend on each other as long >> as the 
>> dependency graph is acyclic. At least the optimizer did all >> this; >> 
>> possibly it went beyond the language definition. Given that >> the 
>> dependency graph is acyclic, it defines a partial >> order on the >> 
>> various elements involved which can be extended to a linear order. >> 
>> Therefore consistent elaboration is >> always possible. >> >> At least 
>> >> some work station compilers require that the dependent declarations 
>> >> actually appear in such a linear order. >> Personal PL/I for OS/2 is 
>> >> one such. I had to rearrange some declare statements to get a couple 
>> of >> my old optimizer >> programs to work. > > The old Language >> 
>> Specification Manual and the (F) Language Reference do indeed allow for 
>> >> such definitions, but the > Enterprise PL/I Language Reference and 
>> the >> 2.3.0 Language Reference agree with me. I can't find a Personal 
>> manual. >> > You are right. The Language Specs and the F reference 
>> manual only >> require the dependency graph to be acyclic. The 
>> Optimizer reference >> manual limits the path length in the dependency 
>> graph to 1. The >> reference manuals for later implementations forbid 
>> dependency >> altogether. Each new implementation waters it down more. 
>> I had never >> noticed that. Nevertheless, at least in Personal PL/I 
>> dependencies work >> if each declarations appears after any items it 
>> depends on. I doubt >> that I ever used more than one level of 
>> dependency. Here is a more >> elaborate example using Personal PL/I for 
>> OS/2. % process mar(2,100) >> offset libs(multi); /* test */ test: proc 
>> options(main) reorder; dcl (i >> init(1),j init((i+1)),k init((j+1)),m 
>> init((i+j+k))) bin fixed, >> sysprint file print; put file(sysprint) 
>> edit(i,j,k,m)(col(1),4 f(4)); >> end test; 5639-C96 IBM Personal PL/I 
>> for OS/2 V1.R2.37 2013.10.19 >> 14:37:32 Copyright (C) IBM Corporation 
>> 1992,1997 Licensed Material - >> Property of IBM. All rights reserved. 
>> File Reference Table File >> Included From Name 1 E:\PLI\test327.pli 
>> Component Return Code Messages >> (Total/Suppressed) Time Compiler 0 0 
>> / 0 0 secs End of compilation of >> TEST IBM(R) Linker for OS/2(R), 
>> Version 01.02.03 (C) Copyright IBM >> Corporation 1988, 1995. (C) 
>> Copyright Microsoft Corp. 1988, 1989. ->> Licensed Material - 
>> Program-Property of IBM - All Rights Reserved.>> ILink : warning 
>> LNK4071: application type not specified; assuming>> WINDOWCOMPAT 1 2 3 
>> 6> > Wasn't the VALUE intended to cover this?
> 
>> Certain problems with INITIAL can be solved by using VALUE instead,
>> but not all. The point of VALUE is to create named constants
>> (as opposed to variables that don't happen to be updated).
> 
> The prime point of VALUE was to simplify the recognition of
> restricted expressions.

That was one reason to create named constants, but not the only one. 
Named constants also provide for generating immediate instructions, 
moving constants from writable-data segments to constant-data segments, 
and other code optimizations.

-- 
John W Kennedy
"The first effect of not believing in God is to believe in anything...."
  -- Emile Cammaerts, "The Laughing Prophet"

0
John
10/20/2013 2:17:19 PM
On Friday, October 18, 2013 2:12:48 PM UTC-5, glen herrmannsfeldt wrote:
> Shmuel (Seymour J.) Metz wrote:
> > on 10/17/2013 at 03:21 AM, glen herrmannsfeldt wrote:
---[---snipped---]---
> Now, why is it that there is JES2 and JES3, but no JES1?
---[---snipped---]---
When my shop was running VS/1 with JES, we used to refer
to it as JES-nothing. ______________ Gerard Schildberger
0
gerardschildberger
10/20/2013 10:27:12 PM
In <l3rupf$136$1@speranza.aioe.org>, on 10/18/2013
   at 06:31 PM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>ASCII text on 36 bit systems is five characters per word.

ASCII text on the PDP-6 and PDP-10 may be five 7-character bytes per
word, but there are also 36-bit machines storing ASCII in 4 9-bit
bytes per word.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
Shmuel
10/23/2013 4:42:48 PM
In <l3s17g$6pc$1@speranza.aioe.org>, on 10/18/2013
   at 07:12 PM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>Now, why is it that there is JES2 and JES3, but no JES1?

Well, there was already a JES on OS/VS1, so the obvious thing to do
was to call the HASP rewrite JES2. I don't know whether the ASP
rewrite was planned at the time.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
Shmuel
10/23/2013 4:46:18 PM
In <l3smta$llu$1@speranza.aioe.org>, on 10/19/2013
   at 01:22 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>And the IBM 36 bit machines used a code called BCD, 

Don't forget SQUOZE. And there was, alas, more than one BCD encoding
on IBM mainframes.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
Shmuel
10/23/2013 4:50:34 PM
In <l3so31$nn2$1@speranza.aioe.org>, on 10/19/2013
   at 01:42 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>Some may have run the 48 character trains on the 1403,

Which, AN or HN?

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
Shmuel
10/23/2013 4:52:40 PM
In <2013101908244121470-jwkenne@attglobalnet>, on 10/19/2013
   at 08:24 AM, John W Kennedy <jwkenne@attglobal.net> said:

>I'm pretty sure QSAM translated 2671 input into EBCDIC.

The only [B|Q]SAM translation that I'm aware of is ASCII-EBCDIC,
unless you are referring to enabling hardware translation.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
Shmuel
10/23/2013 4:56:07 PM
In <Mqs8u.91771$Qj6.59727@fx03.fr7>, on 10/19/2013
   at 10:38 AM, "Peter J. Seymour" <ng@pjsey.demon.co.uk> said:

>I work with a line length that conveniently fits in the editor
>window.

For me, that inluded widths of 132 and 160[1]; I generally kept code
lines *much* shorter than that for readability.

[1] Something about 3290 and cold dead fingers. 

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
Shmuel
10/23/2013 5:00:41 PM
In <wzs8u.227525$G32.84816@fx22.fr7>, on 10/19/2013
   at 10:48 AM, "Peter J. Seymour" <ng@pjsey.demon.co.uk> said:

>I the 1970s I worked at a site that migrated from DOS/VS (with POWER)
>to  OS/VS1 (with a variety of JES).

I would have been called JES, and you probably used RES to submit jobs
remotely.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
Shmuel
10/23/2013 5:01:49 PM
In <l3u2e6$mr6$1@speranza.aioe.org>, on 10/19/2013
   at 01:45 PM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>The actual ASCII-8 table is in the "S/360 Principles of Operation."

A22-6821-7 has it on p 150.1 in Appendix F. USASCII-8 and EBCDIC
Charts.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
Shmuel
10/23/2013 5:08:01 PM
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:

(snip, I wrote)
>>And the IBM 36 bit machines used a code called BCD, 
 
> Don't forget SQUOZE. And there was, alas, more than one BCD encoding
> on IBM mainframes.

Worse than that, more than one encoding on the same machine!

From appendix A of the 704 Fortran manual:

  "Note 1. There are two - signs. Only the 11 punch minus may be
   used in source program cards. Either minus may be used in input
   data to the object program; object program output has the 8-4 
   minus."

Another thing to fix when they went to EBCDIC.

-- glen

0
glen
10/26/2013 12:10:35 AM
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
> In <l3so31$nn2$1@speranza.aioe.org>, on 10/19/2013
>   at 01:42 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
 
>>Some may have run the 48 character trains on the 1403,
 
> Which, AN or HN?

The only ones I remember are PN and QN (and TN), but it looks like
it is HN for Fortran. AN seems to be a commercial train.

GA24-3073-8 on bitsavers has the diagrams, including how many of
each or on each train.

-- glen
 
0
glen
10/26/2013 12:36:22 AM
On 2013-10-23 16:56:07 +0000, Shmuel (Seymour J.) Metz said:

> In <2013101908244121470-jwkenne@attglobalnet>, on 10/19/2013
>    at 08:24 AM, John W Kennedy <jwkenne@attglobal.net> said:
> 
>> I'm pretty sure QSAM translated 2671 input into EBCDIC.
> 
> The only [B|Q]SAM translation that I'm aware of is ASCII-EBCDIC,
> unless you are referring to enabling hardware translation.

For the 2671, both BSAM and QSAM, DEVD=PT,CODE=x, where x was one of 
several allowable letters, each designating a paper-tape code.

I was never even in the same building with a 2671, and I can't find a 
2671 manual now, so I have no idea whether the actual implementation 
was in hardware or software, but it was at least under the control of 
software, and GET or READ normally delivered EBCDIC, one way or t'other.

-- 
John W Kennedy
"The pathetic hope that the White House will turn a Caligula into a 
Marcus Aurelius is as naïve as the fear that ultimate power inevitably 
corrupts."
  -- James D. Barber (1930-2004)


0
John
10/26/2013 1:30:47 AM
On 2013-10-23 16:46:18 +0000, Shmuel (Seymour J.) Metz said:

> In <l3s17g$6pc$1@speranza.aioe.org>, on 10/18/2013
>    at 07:12 PM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
> 
>> Now, why is it that there is JES2 and JES3, but no JES1?
> 
> Well, there was already a JES on OS/VS1, so the obvious thing to do
> was to call the HASP rewrite JES2. I don't know whether the ASP
> rewrite was planned at the time.

I can't speak to planning, but they were announced together as part of 
MVS 2.0 (which was the original version of MVS). I know things weren't 
planned too far ahead, though, because ASP had historically had a 
multiple-console feature that was incompatible with the rather late 
multiple-console feature of OS/360, and it was I, a customer, who 
personally discovered to the JES3 developers that the multiple-console 
feature was to be mandatory on MVS, and that they'd have to redesign 
ASP's console support to deal with it; they were none too happy.

-- 
John W Kennedy
"Though a Rothschild you may be
In your own capacity,
    As a Company you've come to utter sorrow--
But the Liquidators say,
'Never mind--you needn't pay,'
    So you start another company to-morrow!"
  -- Sir William S. Gilbert.  "Utopia Limited"

0
John
10/26/2013 1:39:04 AM
On 10/25/2013 9:30 PM, John W Kennedy wrote:
> On 2013-10-23 16:56:07 +0000, Shmuel (Seymour J.) Metz said:
>
>> In <2013101908244121470-jwkenne@attglobalnet>, on 10/19/2013
>>    at 08:24 AM, John W Kennedy <jwkenne@attglobal.net> said:
>>
>>> I'm pretty sure QSAM translated 2671 input into EBCDIC.
>>
>> The only [B|Q]SAM translation that I'm aware of is ASCII-EBCDIC,
>> unless you are referring to enabling hardware translation.
>
> For the 2671, both BSAM and QSAM, DEVD=PT,CODE=x, where x was one of
> several allowable letters, each designating a paper-tape code.
>
> I was never even in the same building with a 2671, and I can't find a
> 2671 manual now, so I have no idea whether the actual implementation was
> in hardware or software, but it was at least under the control of
> software, and GET or READ normally delivered EBCDIC, one way or t'other.
>

http://www.bookeo.fr/IBM-2671-Paper-Tape-Reader-IBM-2822-Paper-Tape-Reader-Control_a43.html

(I only looked it up because I had no idea what a 2671 was)

-- 
Pete
0
Peter
10/26/2013 12:33:48 PM
On Saturday, October 26, 2013 11:33:48 PM UTC+11, Peter Flass wrote:
> On 10/25/2013 9:30 PM, John W Kennedy wrote:
> On 2013-10-23 16:56:07 +0000, Shmuel (Seymour J.) Metz said:
> >> In <2013101908244121470-jwkenne@attglobalnet>, on 10/19/2013
>> at 08:24 AM, John W Kennedy <xxx...@attglobal.net> said:
>> >>> I'm pretty sure QSAM translated 2671 input into EBCDIC. >> >> The on=
ly [B|Q]SAM translation that I'm aware of is ASCII-EBCDIC, >> unless you ar=
e referring to enabling hardware translation. > > For the 2671, both BSAM a=
nd QSAM, DEVD=3DPT,CODE=3Dx, where x was one of > several allowable letters=
, each designating a paper-tape code. > > I was never even in the same buil=
ding with a 2671, and I can't find a > 2671 manual now, so I have no idea w=
hether the actual implementation was > in hardware or software, but it was =
at least under the control of > software, and GET or READ normally delivere=
d EBCDIC, one way or t'other. > http://www.bookeo.fr/IBM-2671-Paper-Tape-Re=
ader-IBM-2822-Paper-Tape-Reader-Control_a43.html (I only looked it up becau=
se I had no idea what a 2671 was) -- Pete

There were two forms of the paper tape reader:
One without spooling, ran at 1,000 cps.
After fitting spooling to the same device,
the speed was 500 cps.  Great improvement !
0
robin
10/26/2013 3:53:47 PM
On 26/10/2013 02:30, John W Kennedy wrote:
> On 2013-10-23 16:56:07 +0000, Shmuel (Seymour J.) Metz said:
>
>> In <2013101908244121470-jwkenne@attglobalnet>, on 10/19/2013
>>    at 08:24 AM, John W Kennedy <jwkenne@attglobal.net> said:
>>
>>> I'm pretty sure QSAM translated 2671 input into EBCDIC.
>>
>> The only [B|Q]SAM translation that I'm aware of is ASCII-EBCDIC,
>> unless you are referring to enabling hardware translation.
>
> For the 2671, both BSAM and QSAM, DEVD=PT,CODE=x, where x was one of
> several allowable letters, each designating a paper-tape code.
>
> I was never even in the same building with a 2671, and I can't find a
> 2671 manual now, so I have no idea whether the actual implementation was
> in hardware or software, but it was at least under the control of
> software, and GET or READ normally delivered EBCDIC, one way or t'other.
>
I don't remember the number but 2671 certainly looks like the paper tape 
reader I used in the dim distant past. Our installation had a typing 
pool that used paper tape punches inherited from an ancient ICL
(ICT ?) system. We continued to use them with a IBM DOS/VS system. The 
2671 certainly looks like the reader we used. I used it many times. You 
feed the tape through when required by the 370. Then at a convenient 
moment you rewound the tape in case it was needed for correction and 
re-run. The data once read had to be processed by an in-house conversion 
routine that translated the obscure input data into something that the 
IBM mainframe could understand. Eventually all of that palaver was 
scrapped and the punch girls (there weren't any boys) used direct data 
entry keying equipment instead. At about the same time we programmers 
changed from using punched cards to on-line editing (SPMOL/II I think).

0
Peter
10/26/2013 7:40:58 PM
On 10/26/2013 11:53 AM, robin.vowels@gmail.com wrote:
> On Saturday, October 26, 2013 11:33:48 PM UTC+11, Peter Flass wrote:
>> On 10/25/2013 9:30 PM, John W Kennedy wrote:
>> On 2013-10-23 16:56:07 +0000, Shmuel (Seymour J.) Metz said:
>>>> In <2013101908244121470-jwkenne@attglobalnet>, on 10/19/2013
>>> at 08:24 AM, John W Kennedy <xxx...@attglobal.net> said:
>>>>>> I'm pretty sure QSAM translated 2671 input into EBCDIC. >> >> The only [B|Q]SAM translation that I'm aware of is ASCII-EBCDIC, >> unless you are referring to enabling hardware translation. > > For the 2671, both BSAM and QSAM, DEVD=PT,CODE=x, where x was one of > several allowable letters, each designating a paper-tape code. > > I was never even in the same building with a 2671, and I can't find a > 2671 manual now, so I have no idea whether the actual implementation was > in hardware or software, but it was at least under the control of > software, and GET or READ normally delivered EBCDIC, one way or t'other. > http://www.bookeo.fr/IBM-2671-Paper-Tape-Reader-IBM-2822-Paper-Tape-Reader-Control_a43.html (I only looked it up because I had no idea what a 2671 was) -- Pete
>
> There were two forms of the paper tape reader:
> One without spooling, ran at 1,000 cps.
> After fitting spooling to the same device,
> the speed was 500 cps.  Great improvement !
>

Raw device thruput maybe, but what did it do to the rest of the system. 
  Since most card/paper tape readers were idle most of the time the 
slowdown was probably relatively insignificant.

You were probably using a lousy spooler. HASP could usually run 
readers/punches/printers at close to their rated speeds, but I expect 
HASP didn't support paper tape.

-- 
Pete
0
Peter
10/26/2013 11:12:53 PM
On Sunday, October 27, 2013 10:12:53 AM UTC+11, Peter Flass wrote:
> On 10/26/2013 11:53 AM, Rxxxx...@gmail.com wrote: > On Saturday, October =
26, 2013 11:33:48 PM UTC+11, Peter Flass wrote: >> On 10/25/2013 9:30 PM, J=
ohn W Kennedy wrote: >> On 2013-10-23 16:56:07 +0000, Shmuel (Seymour J.) M=
etz said: >>>> In <2013101908244121470-jwkenne@attglobalnet>, on 10/19/2013=
 >>> at 08:24 AM, John W Kennedy <xxx...@attglobal.net> said: >>>>>> I'm pr=
etty sure QSAM translated 2671 input into EBCDIC. >> >> The only [B|Q]SAM t=
ranslation that I'm aware of is ASCII-EBCDIC, >> unless you are referring t=
o enabling hardware translation. > > For the 2671, both BSAM and QSAM, DEVD=
=3DPT,CODE=3Dx, where x was one of > several allowable letters, each design=
ating a paper-tape code. > > I was never even in the same building with a 2=
671, and I can't find a > 2671 manual now, so I have no idea whether the ac=
tual implementation was > in hardware or software, but it was at least unde=
r the control of > software, and GET or READ normally delivered EBCDIC, one=
 way or t'other. > http://www.bookeo.fr/IBM-2671-Paper-Tape-Reader-IBM-2822=
-Paper-Tape-Reader-Control_a43.html (I only looked it up because I had no i=
dea what a 2671 was) -- Pete
>> > There were two forms of the paper tape reader:
>> One without spooling, ran at 1,000 cps.
>> After fitting spooling to the same device,
>> the speed was 500 cps. Great improvement !

> Raw device thruput maybe, but what did it do to
? the rest of the system. Since most card/paper
> tape readers were idle most of the time

The card reader was busy much of the time,
as was the printer.
Guess it depended on what the jobs were.
we had lotsa short jobs.

> the slowdown was probably relatively insignificant.

Significant under PCP.

> You were probably using a lousy spooler.

It was standard IBM equipment.

> HASP could usually run readers/punches/printers
> at close to their rated speeds, but I expect HASP
> didn't support paper tape.

No reason why not.
The PTR was just another device, like mag tape.

0
robin
10/26/2013 11:47:08 PM
On 2013-10-26 15:53:47 +0000, robin.vowels@gmail.com said:

> On Saturday, October 26, 2013 11:33:48 PM UTC+11, Peter Flass wrote:
>> On 10/25/2013 9:30 PM, John W Kennedy wrote:
>> On 2013-10-23 16:56:07 +0000, Shmuel (Seymour J.) Metz said:
>>>> In <2013101908244121470-jwkenne@attglobalnet>, on 10/19/2013
>>> at 08:24 AM, John W Kennedy <xxx...@attglobal.net> said:
>>>>>> I'm pretty sure QSAM translated 2671 input into EBCDIC. >> >> The only 
>>>>>> [B|Q]SAM translation that I'm aware of is ASCII-EBCDIC, >> unless you 
>>>>>> are referring to enabling hardware translation. > > For the 2671, both 
>>>>>> BSAM and QSAM, DEVD=PT,CODE=x, where x was one of > several allowable 
>>>>>> letters, each designating a paper-tape code. > > I was never even in 
>>>>>> the same building with a 2671, and I can't find a > 2671 manual now, so 
>>>>>> I have no idea whether the actual implementation was > in hardware or 
>>>>>> software, but it was at least under the control of > software, and GET 
>>>>>> or READ normally delivered EBCDIC, one way or t'other. > 
>>>>>> http://www.bookeo.fr/IBM-2671-Paper-Tape-Reader-IBM-2822-Paper-Tape-Reader-Control_a43.html 
>>>>>> (I only looked it up because I had no idea what a 2671 was) -- Pete
> 
> There were two forms of the paper tape reader:
> One without spooling, ran at 1,000 cps.
> After fitting spooling to the same device,
> the speed was 500 cps.  Great improvement !

As far as I can tell, it's referring to literal spools, not SPOOLing. 
And it was 500 to 1000 cps, "depending on the record length". Probably 
a question of accelerating and decelerating the spools.

-- 
John W Kennedy
"The whole modern world has divided itself into Conservatives and 
Progressives. The business of Progressives is to go on making mistakes. 
The business of the Conservatives is to prevent the mistakes from being 
corrected."
  -- G. K. Chesterton

0
John
10/27/2013 3:53:05 PM
On Monday, October 28, 2013 2:53:05 AM UTC+11, John W Kennedy wrote:
> On 2013-10-26 15:53:47 +0000, ro.nospam@gmail.com said: > On Saturday, Oc=
tober 26, 2013 11:33:48 PM UTC+11, Peter Flass wrote: >> On 10/25/2013 9:30=
 PM, John W Kennedy wrote: >> On 2013-10-23 16:56:07 +0000, Shmuel (Seymour=
 J.) Metz said: >>>> In <2013101908244121470-jwkenne@attglobalnet>, on 10/1=
9/2013 >>> at 08:24 AM, John W Kennedy <xxx...@attglobal.net> said: >>>>>> =
I'm pretty sure QSAM translated 2671 input into EBCDIC. >> >> The only >>>>=
>> [B|Q]SAM translation that I'm aware of is ASCII-EBCDIC, >> unless you >>=
>>>> are referring to enabling hardware translation. > > For the 2671, both=
 >>>>>> BSAM and QSAM, DEVD=3DPT,CODE=3Dx, where x was one of > several all=
owable >>>>>> letters, each designating a paper-tape code. > > I was never =
even in >>>>>> the same building with a 2671, and I can't find a > 2671 man=
ual now, so >>>>>> I have no idea whether the actual implementation was > i=
n hardware or >>>>>> software, but it was at least under the control of > s=
oftware, and GET >>>>>> or READ normally delivered EBCDIC, one way or t'oth=
er. > >>>>>> http://www.bookeo.fr/IBM-2671-Paper-Tape-Reader-IBM-2822-Paper=
-Tape-Reader-Control_a43.html >>>>>> (I only looked it up because I had no =
idea what a 2671 was) -- Pete

>> There were two forms of the paper tape reader:=20
>> One without spooling, ran at 1,000 cps.
>> After fitting spooling to the same device,
>> the speed was 500 cps. Great improvement !

> As far as I can tell, it's referring to literal spools,

That's what I said.

> not SPOOLing. And it was 500 to 1000 cps,

500cps max. after fitting the spooling equipment.

> "depending on the record length".

Nothing to do with the record length.

> Probably a question of accelerating and decelerating the spools.

Somewhat ponderous in operation.
0
robin
10/28/2013 12:14:27 AM
On 2013-10-28 00:14:27 +0000, robin.vowels@gmail.com said:

> On Monday, October 28, 2013 2:53:05 AM UTC+11, John W Kennedy wrote:
>> On 2013-10-26 15:53:47 +0000, ro.nospam@gmail.com said: > On Saturday, 
>> October 26, 2013 11:33:48 PM UTC+11, Peter Flass wrote: >> On 
>> 10/25/2013 9:30 PM, John W Kennedy wrote: >> On 2013-10-23 16:56:07 
>> +0000, Shmuel (Seymour J.) Metz said: >>>> In 
>> <2013101908244121470-jwkenne@attglobalnet>, on 10/19/2013 >>> at 08:24 
>> AM, John W Kennedy <xxx...@attglobal.net> said: >>>>>> I'm pretty sure 
>> QSAM translated 2671 input into EBCDIC. >> >> The only >>>>>> [B|Q]SAM 
>> translation that I'm aware of is ASCII-EBCDIC, >> unless you >>>>>> are 
>> referring to enabling hardware translation. > > For the 2671, both 
>> >>>>>> BSAM and QSAM, DEVD=PT,CODE=x, where x was one of > several 
>> allowable >>>>>> letters, each designating a paper-tape code. > > I was 
>> never even in >>>>>> the same building with a 2671, and I can't find a 
>> > 2671 manual now, so >>>>>> I have no idea whether the actual 
>> implementation was > in hardware or >>>>>> software, but it was at 
>> least under the control of > software, and GET >>>>>> or READ normally 
>> delivered EBCDIC, one way or t'other. > >>>>>> 
>> http://www.bookeo.fr/IBM-2671-Paper-Tape-Reader-IBM-2822-Paper-Tape-Reader-Control_a43.html 
>> >>>>>> (I only looked it up because I had no idea what a 2671 was) -- 
>> Pete
> 
>>> There were two forms of the paper tape reader:>> One without spooling, 
>>> ran at 1,000 cps.
>>> After fitting spooling to the same device,
>>> the speed was 500 cps. Great improvement !
> 
>> As far as I can tell, it's referring to literal spools,
> 
> That's what I said.

Yes, but everyone else in the thread thought otherwise.

>> not SPOOLing. And it was 500 to 1000 cps,
> 
> 500cps max. after fitting the spooling equipment.

That's not what the S/360 System Summary says, along with its followups 
through 1980, which is the only genuine IBM doc relating to the 2671 
that I can find on-line.

>> "depending on the record length".
> 
> Nothing to do with the record length.

Again, the S/360 System Summary says so, in so many words. 500 to 1000 
cps depending on record length -- and it said that for at least 16 
years.

>> Probably a question of accelerating and decelerating the spools.
> 
> Somewhat ponderous in operation.

They would be. Look at what an engineering kludge 2400' magtape drives 
were -- and paper tape is a lot more fragile.

-- 
John W Kennedy
"There are those who argue that everything breaks even in this old dump 
of a world of ours. I suppose these ginks who argue that way hold that 
because the rich man gets ice in the summer and the poor man gets it in 
the winter things are breaking even for both. Maybe so, but I'll swear 
I can't see it that way."
  -- The last words of Bat Masterson

0
John
10/28/2013 1:48:13 AM
On 10/27/2013 9:48 PM, John W Kennedy wrote:
> On 2013-10-28 00:14:27 +0000, robin.vowels@gmail.com said:
>
>> On Monday, October 28, 2013 2:53:05 AM UTC+11, John W Kennedy
>> wrote:
>>> On 2013-10-26 15:53:47 +0000, ro.nospam@gmail.com said: > On
>>> Saturday, October 26, 2013 11:33:48 PM UTC+11, Peter Flass wrote:
>>> >> On 10/25/2013 9:30 PM, John W Kennedy wrote: >> On 2013-10-23
>>>  16:56:07 +0000, Shmuel (Seymour J.) Metz said: >>>> In
>>> <2013101908244121470-jwkenne@attglobalnet>, on 10/19/2013 >>> at
>>>  08:24 AM, John W Kennedy <xxx...@attglobal.net> said: >>>>>> I'm
>>>  pretty sure QSAM translated 2671 input into EBCDIC. >> >> The
>>> only
>>>>>>>>> [B|Q]SAM translation that I'm aware of is
>>>>>>>>> ASCII-EBCDIC, >>
>>> unless you >>>>>> are referring to enabling hardware translation.
>>> > > For the 2671, both >>>>>> BSAM and QSAM, DEVD=PT,CODE=x,
>>> where x was one of > several allowable >>>>>> letters, each
>>> designating a paper-tape code. > > I was never even in >>>>>> the
>>> same building with a 2671, and I can't find a > 2671 manual now,
>>> so >>>>>> I have no idea whether the actual implementation was >
>>> in hardware or >>>>>> software, but it was at least under the
>>> control of > software, and GET >>>>>> or READ normally delivered
>>> EBCDIC, one way or t'other. >
>>>>>>>>>
>>> http://www.bookeo.fr/IBM-2671-Paper-Tape-Reader-IBM-2822-Paper-Tape-Reader-Control_a43.html
>>>
>>>>>>>>> (I only looked it up because I had no idea what a
>>>>>>>>> 2671 was) --
>>> Pete
>>
>>>> There were two forms of the paper tape reader:>> One without
>>>> spooling, ran at 1,000 cps. After fitting spooling to the same
>>>> device, the speed was 500 cps. Great improvement !
>>
>>> As far as I can tell, it's referring to literal spools,
>>
>> That's what I said.
>
> Yes, but everyone else in the thread thought otherwise.
>
>>> not SPOOLing. And it was 500 to 1000 cps,
>>
>> 500cps max. after fitting the spooling equipment.
>
> That's not what the S/360 System Summary says, along with its
> followups through 1980, which is the only genuine IBM doc relating to
> the 2671 that I can find on-line.

Did you check the link I posted?

-- 
Pete
0
Peter
10/28/2013 11:26:42 AM
On Monday, October 28, 2013 12:48:13 PM UTC+11, John W Kennedy wrote:
> On 2013-10-28 00:14:27 +0000, ro.nospam@gmail.com said: > On Monday, Octo=
ber 28, 2013 2:53:05 AM UTC+11, John W Kennedy wrote: >> On 2013-10-26 15:5=
3:47 +0000, ro.nospam@gmail.com said: > On Saturday, >> October 26, 2013 11=
:33:48 PM UTC+11, Peter Flass wrote: >> On >> 10/25/2013 9:30 PM, John W Ke=
nnedy wrote: >> On 2013-10-23 16:56:07 >> +0000, Shmuel (Seymour J.) Metz s=
aid: >>>> In >> <2013101908244121470-jwkenne@attglobalnet>, on 10/19/2013 >=
>> at 08:24 >> AM, John W Kennedy <xxx...@attglobal.net> said: >>>>>> I'm p=
retty sure >> QSAM translated 2671 input into EBCDIC. >> >> The only >>>>>>=
 [B|Q]SAM >> translation that I'm aware of is ASCII-EBCDIC, >> unless you >=
>>>>> are >> referring to enabling hardware translation. > > For the 2671, =
both >> >>>>>> BSAM and QSAM, DEVD=3DPT,CODE=3Dx, where x was one of > seve=
ral >> allowable >>>>>> letters, each designating a paper-tape code. > > I =
was >> never even in >>>>>> the same building with a 2671, and I can't find=
 a >> > 2671 manual now, so >>>>>> I have no idea whether the actual >> imp=
lementation was > in hardware or >>>>>> software, but it was at >> least un=
der the control of > software, and GET >>>>>> or READ normally >> delivered=
 EBCDIC, one way or t'other. > >>>>>> >> http://www.bookeo.fr/IBM-2671-Pape=
r-Tape-Reader-IBM-2822-Paper-Tape-Reader-Control_a43.html >> >>>>>> (I only=
 looked it up because I had no idea what a 2671 was) -- >> Pete > >>> There=
 were two forms of the paper tape reader:>> One without spooling, >>> ran a=
t 1,000 cps. >>> After fitting spooling to the same device, >>> the speed w=
as 500 cps. Great improvement ! > >> As far as I can tell, it's referring t=
o literal spools, > > That's what I said. Yes, but everyone else in the thr=
ead thought otherwise. >> not SPOOLing. And it was 500 to 1000 cps, > > 500=
cps max. after fitting the spooling equipment. That's not what the S/360 Sy=
stem Summary says, along with its followups through 1980, which is the only=
 genuine IBM doc relating to the 2671 that I can find on-line. >> "dependin=
g on the record length".=20

> > Nothing to do with the record length. Again, the S/360 System Summary s=
ays so, in so many words. 500 to 1000 cps depending on record length -- and=
 it said that for at least 16 years.=20

It might have said something like that, but in practice,
it was 500 cps.  The tape stopped whenever the spools wound on,
which was a slow process.

>> Probably a question of accelerating and decelerating the spools. > > Som=
ewhat ponderous in operation. They would be. Look at what an engineering kl=
udge 2400' magtape drives were -- and paper tape is a lot more fragile.

0
robin
10/28/2013 2:31:35 PM
On 2013-10-28 11:26:42 +0000, Peter Flass said:

> On 10/27/2013 9:48 PM, John W Kennedy wrote:
>> On 2013-10-28 00:14:27 +0000, robin.vowels@gmail.com said:
>> 
>>> On Monday, October 28, 2013 2:53:05 AM UTC+11, John W Kennedy
>>> wrote:
>>>> On 2013-10-26 15:53:47 +0000, ro.nospam@gmail.com said: > On
>>>> Saturday, October 26, 2013 11:33:48 PM UTC+11, Peter Flass wrote:
>>>>>> On 10/25/2013 9:30 PM, John W Kennedy wrote: >> On 2013-10-23
>>>> 16:56:07 +0000, Shmuel (Seymour J.) Metz said: >>>> In
>>>> <2013101908244121470-jwkenne@attglobalnet>, on 10/19/2013 >>> at
>>>> 08:24 AM, John W Kennedy <xxx...@attglobal.net> said: >>>>>> I'm
>>>> pretty sure QSAM translated 2671 input into EBCDIC. >> >> The
>>>> only
>>>>>>>>>> [B|Q]SAM translation that I'm aware of is
>>>>>>>>>> ASCII-EBCDIC, >>
>>>> unless you >>>>>> are referring to enabling hardware translation.
>>>>>> For the 2671, both >>>>>> BSAM and QSAM, DEVD=PT,CODE=x,
>>>> where x was one of > several allowable >>>>>> letters, each
>>>> designating a paper-tape code. > > I was never even in >>>>>> the
>>>> same building with a 2671, and I can't find a > 2671 manual now,
>>>> so >>>>>> I have no idea whether the actual implementation was >
>>>> in hardware or >>>>>> software, but it was at least under the
>>>> control of > software, and GET >>>>>> or READ normally delivered
>>>> EBCDIC, one way or t'other. >
>>>>>>>>>> 
>>>> http://www.bookeo.fr/IBM-2671-Paper-Tape-Reader-IBM-2822-Paper-Tape-Reader-Control_a43.html 
>>>> 
>>>> 
>>>>>>>>>> (I only looked it up because I had no idea what a
>>>>>>>>>> 2671 was) --
>>>> Pete
>>> 
>>>>> There were two forms of the paper tape reader:>> One without
>>>>> spooling, ran at 1,000 cps. After fitting spooling to the same
>>>>> device, the speed was 500 cps. Great improvement !
>>> 
>>>> As far as I can tell, it's referring to literal spools,
>>> 
>>> That's what I said.
>> 
>> Yes, but everyone else in the thread thought otherwise.
>> 
>>>> not SPOOLing. And it was 500 to 1000 cps,
>>> 
>>> 500cps max. after fitting the spooling equipment.
>> 
>> That's not what the S/360 System Summary says, along with its
>> followups through 1980, which is the only genuine IBM doc relating to
>> the 2671 that I can find on-line.
> 
> Did you check the link I posted?

I found the webpage, but I clicked and dragged every which way I could 
think of and couldn't find anything but the manual's cover page. 
Perhaps my French is inadequate -- it's just barely good enough to 
order a meal at a Tim Horton's in Québec, but no more.

-- 
John W Kennedy
"You can, if you wish, class all science-fiction together; but it is 
about as perceptive as classing the works of Ballantyne, Conrad and W. 
W. Jacobs together as the 'sea-story' and then criticizing _that_."
  -- C. S. Lewis.  "An Experiment in Criticism"

0
John
10/28/2013 3:16:11 PM
In <l4f2q6$bln$1@speranza.aioe.org>, on 10/26/2013
   at 12:36 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>The only ones I remember are PN and QN

Those are 4 sets of 60, not 5 sets of 48. The common trains with 5
sets of 48 were AN and HN.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
Shmuel
11/22/2013 3:54:04 AM
In <2013102521304733090-jwkenne@attglobalnet>, on 10/25/2013
   at 09:30 PM, John W Kennedy <jwkenne@attglobal.net> said:

>For the 2671, both BSAM and QSAM, DEVD=PT,CODE=x, where x was one 
>of several allowable letters, each designating a paper-tape code.

I checked the PLM and you're right, it is indeed a software
translation. 

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
Shmuel
11/22/2013 4:04:09 AM
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
> In <l4f2q6$bln$1@speranza.aioe.org>, on 10/26/2013
>   at 12:36 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
 
>>The only ones I remember are PN and QN
 
> Those are 4 sets of 60, not 5 sets of 48. The common trains with 5
> sets of 48 were AN and HN.

Yes, the systems I remember never ran 48 character trains. 

Usually TN only ran at night.

At some point, they started running the printers at 8 lines/inch with
8.5x14 paper to save on paper costs. I believe with trains with
characters not quite as tall. 

Night TN runs were still on 11x14 paper at 6lpi.

-- glen
0
glen
11/22/2013 9:58:24 PM
On 2013-11-22 03:54:04 +0000, Shmuel (Seymour J.) Metz said:

> In <l4f2q6$bln$1@speranza.aioe.org>, on 10/26/2013
>    at 12:36 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
> 
>> The only ones I remember are PN and QN
> 
> Those are 4 sets of 60,

That was PN. QN was a mixed-frequency set that contained 5 of most of 
the HN set, but only 1 or 2  of the remaining characters of the 
60-character set. There was also QNC, like QN, but based on the AN set 
("C" for "Commercial").

> not 5 sets of 48. The common trains with 5
> sets of 48 were AN and HN.

-- 
John W Kennedy
"Never try to take over the international economy based on a radical 
feminist agenda if you're not sure your leader isn't a transvestite."
  -- David Misch:  "She-Spies", "While You Were Out"

0
John
11/23/2013 1:47:18 AM
Reply:

Similar Artilces:

Need Suggestion for migrating to Java from PL1 project
Dear friends, I involved in a migration project from PL1 to Java. I have no such experience before. The PL1 source code is more than 200,000 lines! I doubt I have enough time to read and understand it. I'd very appreciated if you may recommend some strategics,methods or tools for this work. Is there any tools to analysis PL1 codes? Thanks in advance! "kelvin" <shaojun1979@gmail.com> wrote in message news:1a2c09e5-e7b7-4abb-91cd-89f86d1a2c05@h14g2000pri.googlegroups.com... | Dear friends, I involved in a migration project from PL1 to Java. I | have no such experi...

Are the PL1 run-time components available on all zOS sites ?
Dear zOS PL1 experts, I am wondering if an application developed in PL1 can be executed on any zOS site or if it requires run-time components available only on sites licensing the PL1 compiler. Any information is welcome. Wish you a good week-end. Renaud. On Friday, October 18, 2013 10:50:36 PM UTC+11, renau...@gmail.com wrote: > Dear zOS PL1 experts, I am wondering if an application developed in PL1 can be executed on any zOS site or if it requires run-time components available only on sites licensing the PL1 compiler. Any information is welcome. Wish you a good week-end. Run-time components can be incorporated (linked) with the PL/I executable and thus run on any IBM site, regardless of whether a PL/I implementation is available on that site. No license fee is required. > Run-time components can be incorporated (linked) with the PL/I executable Thanks Robin. When you say 'can be', do you mean this is not the default ? Does this require some specific options on the compile/bind steps ? ...

AGS issues issues issues
Using AGS3 on my apple IIc all I can reliably do is crash any tips? On Sunday, November 18, 2012 5:42:33 PM UTC-6, Kevin wrote: > Using AGS3 on my apple IIc all I can reliably do is crash any tips? I recommend tracking down the author and giving him a really good piece of = your mind about how little he's updated that project recently... oh wait (l= ooks in mirror) that would be me. ;-) Yes, actually I developed it with a Rev-0 //c so I know it can work. :-) T= ry toggling the "debug bootstrap" parameter. That tends to help a bit. I need to scrub through the c...

Any Migration issues???
Hi, can anyone let me know whether there are any known issues for the following migration: 1) Migrating a web application (classic ASP 3.0) from Windows NT to Windows 2000. 2) Migrating the corresponding database tables from MS SQL Server 6.5 to MS SQL Server 2000. Many thanks in advance. Rgds ls_ng ...

PL1 and SQL
The common way of accessing a data base has been exec sql .. .. .. .. .. some sql statements .. .. .. end-exec Questions: has this been changed? where can i define which database the compiler shall access? Thanks Robert -- 'Vom Standpunkt eines Beamtenrechtlers aus betrachtet ist der Tod die sch�rfstwirkenste aller bekannten, langfristig wirkenden Formen der vollst�ndigen Dienstunf�higkeit.' aus: Kommentar zum Beamtenrecht. R.Freitag wrote: > The common way of accessing a data base has been > > exec sql > .. > .. > .. > .. > .. some sql statements >...

Migration Issue
Forgive my newbie status. I've got a few books and many webpages bookmarked, but I haven't found an answer to this question. I'm migrating our SQL Server database to Oracle (by hand!), and currently attempting to convert a table which contains a column with a SS7 datatype called "uniqueidentifier" with the property ROWGUIDCOL. As far as I can tell, this means that the column will contain a value which is unique in the database -- no other row in any other table in the database will have the same value. Is there similar functionality in Oracle? How do I describe the equivalent table in Oracle? Richard Crawford <rcrawford.cow@remove_herbivore.unexmail.ucdavis.edu> wrote: >Forgive my newbie status. I've got a few books and many webpages >bookmarked, but I haven't found an answer to this question. > >I'm migrating our SQL Server database to Oracle (by hand!), and >currently attempting to convert a table which contains a column with a >SS7 datatype called "uniqueidentifier" with the property ROWGUIDCOL. As >far as I can tell, this means that the column will contain a value which >is unique in the database -- no other row in any other table in the >database will have the same value. > >Is there similar functionality in Oracle? How do I describe the >equivalent table in Oracle? Look in your sources ( books or sites) for the use of Oracle Sequenc...

Any PL1 for Linux?
That's the essence of it - is there any PL/1 for Linux available? (I know there's PL/1 for VM/??? - I've got it in my VM/370 running in Hercules and in MVS3.8j running in the same environment; I've even got it in CP/M running in the SIMH altairz80 simulator ... ;) Thanks Wesley Parish -- "Good, late in to more rewarding well."  "Well, you tonight.  And I was lookintelligent woman of Ming home.  I trust you with a tender silence."  I get a word into my hands, a diffe...

Converting from PL1
With the news that IBM is planning to discontinue support for VisualAge PLI for Windows I am considering converting our PL1 programs to another language and am trying to decide what the best language would be. My platform is Windows XP desktops and Windows 2003 servers. The programs I am looking to convert are all command line / batch processing type programs and I want to keep it that way for these programs. Here are the things these programs do. 1. Read files with a large number of records. These recordsets come in csv, tab delimited, fixed length record and some other layouts. 2. Do a ...

PL1 to UML
Hello all Is someone aware of any tool that can convert PL1 to UML? Thanks in advance Andre Cavadas On Mon, 14 May 2007 10:05:43 -0700, <serralheiro@gmail.com> wrote: > Hello all > > Is someone aware of any tool that can convert PL1 to UML? It is PL/I not PL1 and your query doesn't make sense. UML is a design tool, which conceivably could have language specific backends such as PL/I. In this sense it is a program generator. But, BTW, I have seen many tools like this come and go over the past 40 years, The mean time between fashions seems to be somewhere between 6...

Migration issues
I am contemplating changing my development hardware, OS, and version of VO. I am looking for information and advice as I work my way through this transition. I am currently running VO 2.5b under XP. I use this with Advantage and ReportPro 2. Except for repo issues, this has been a reasonably good combination for me. I want to end up running VO 2.8 under Vista still using Advantage and ReportPro. As I understand it from reading this newsgroup, VO 2.5 under Vista is a painful experience. I haven't been able to sort out whether it works to run it in XP Compatibility mode or not -...

Migration Issue...
I have a Symm array and we are moving to DMX array .. what is the least impact on production user's to move the data from sym to dmx . The servers are using veritas volume manager .. would it be simpler to import the vg or use another tool. we are looking for the least interruption to productivity .. Can we mirror the data from on server to another? then break the mirror and point users to new vg? Need some suggestions ...

Migration Issues
Hi, I have some questions on the migration on from PPC2003 1. How long would it take to migrate PPC2003 to a new board? 2. What are the issues involved in migration? Any links/ideas/pointers would be usefule Thanks in advance Ed ...

1. Redhat linux 7.2 issue 2. Redhat enterprise linux issue
Hi -- I have two issues I need your help on, 1. We have a redhat linux 7.2 on a pentium-3 machine with 256MB RAM. It is in a LAN that has multiple redhat linux 9.0, redhat enterprise linux servers, solaris,etc.. I configured NIS and made this client part of it. The user home areas are automounted. So on a redhat 9 system when a user logs in, the user goes to his home directory by default. But when I logon the console of 7.2, I get a message that 'home not found, hence logging with / as the home'. I gave this a fix by asking the user to login as root on the machine and doing a su - $u...

ORACLE MIGRATION ISSUES
1. In the oracle trigger we have a SINGLE INSERT STORED PROCEDURE CALLED MUTLIPLE TIMES with different values. But when changed to DB2, it gives SQL -746 ?? Any help?? 2. In oracle we have Create or replace TYPE TEST_TYPE AS OBJECT ( ....,....) Create or replace TYPE TEST_TABLE AS TABLE OF TEST_TYPE This is used in a FUNCTION to return RESULT SET HAVING DATA AS IN A TABLE AND this TABLE IS USED in JOINS in the application. How do we do it in DB2?? 3. Can a UDF call a STORED PROCEDURE OR TRIGGER in DB2? db2sysc@yahoo.com wrote: > 1. In the oracle trigger we ...

VisualAge PL1 for Windows
2 questions. 1. What is the current version for VisualAge PL1 for Windows? My version is V2.R1.08 and was wondering if something newer is available. 2. Is IBM planning a version for the 64 bit Windows? Thanks Randy Gress The most current IBM "windows" targetted PL/I product is the PL/I compoent of "WebSphere Studio Enterprise Developer" Check out: http://www-306.ibm.com/software/awdtools/studioenterprisedev/ You can get the Programming Guide from: http://www-1.ibm.com/support/docview.wss?&uid=swg27005323 (I don't know the answer to the 64-bit quest...

PL1 Source Library
I want to save some PL/I to the Source Library and then create another new program which is a duplicate of this code. How can this be done and where can I find information on how to save programs to the Source Library? I think we need some more information to help you. What operating system (O/S)? What type of "source library" are you using? Depending on the answers to those two questions, we probably can help, but the answer is almost always "do the same thing you would do for any other type of source in this environment" -- Bill Klein wmklein <at> ix.netc...

DB Migration Issues
Hi, I have several homogeneous SUSE 9 Nodes. I am running BDB4.3.28 with following configuration parameters. DB Flags = DB_CREATE| DB_AUTO_COMMIT|DB_THREAD; Env Flags = DB_RECOVER |DB_CREATE | DB_INIT_LOG | DB_INIT_MPOOL | DB_INIT_TXN|DB_THREAD; I have configured transaction subsystem with DB_TXN_WRITE_NOSYNC| DB_LOG_AUTOREMOVE options. I want to copy the DB from one machine to another machine. Suggested method is using db_dump and db_load. But this transfer has to be done every 5 minutes, so using db_dump and db_load is not possible as it takes lot of time. The DB File...

PL1 on Windows 64bit machines
So I'm back briefly after a long gap. I recognise most of the names :-) I'm looking for an officially supported by IBM PL1 compiler that runs under Windows 7 (either 32 or 64 bit, it's not too important) and the executables must run on 64 bit windows machines (Windows 2008 servers, I think). The executables must also be callable from Visual Studio (this works fine using our old code compiled with our VisualAge PL/I for Windows V2.R1.08 compiler). Will the compiler that comes in the Enterprise zOS package do the trick? Can anyone help shed some light please? ...

sql server migration issues
we recentely tried migrating our databases from 2000 to sql server 2005.The migrated databases had some issues like collation issues,so we created the scripts for each databases and then updated these scripts to remove collation issues to make these compatible to SQL server 2005. But we have some permission issues for the users in case of these created databases i.e. we are unable to see all the tables with ssupdate user id ,or any other id .except the dbo id which is the owner of this database,where we can see all the tables and stored procedures. iam fairly new at sql server .does anyone hav...

RP2 to RP3 migration issue
Hi All, I want to know a migration issue for RP2 to RP3. And anyone can share a code sample using RP3 without resorting to OCX? I still prefers RP2 style but I need to migrate to RP3. Please send your code sample to coop-it at pfcco.coop Thank you very much, Rene Rene, Feel free to download some sample VO for RP3 code (no OCX required) from our web site www.control.net.au Go to Links, VO Resources, then CdReportServerV35 Been using it ever since RP3 was released and it works great. Craig. -------- "Rene J. Pajaron" <rjpajaron@yahoo.com> wro...

Oracle to DB2 Migration issues
Hi, I'm a developer for a software application vendor, and our application makes use of a customer-maintained Oracle 8i/9i database. We've had a customer request to support DB2 database, and I'm looking into the feasibility of migration. Our application runs on NT Server and, the DB2 database would be in some cases on a separate AIX machine, in other cases on an AS/400. There are two problems we are running into, both relating to our use of Oracle Supplied Packages: First, we make use of the DBMS_PIPE Oracle Supplied Package to communicate from a trigger back to our...

Dolphin X6 PL1 Available
Folks, We have released a "final" patch level 1 for Dolphin X6. This can be installed into your current image using the Live Update icon from the system folder. Once you have installed this, the Dolphin splash screen should announce the version number as "6.0 PL1". You can read about the list of changes in the patch by clicking the Help button in Live Update with the patch selected. Alternatively, you can follow this link: http://www.object-arts.com/Lib/Update/Dolphin/6.0/Professional/PL1.htm As with any Live Update, we would recommend that you create a bac...

Any PL1 Jobs/Work available?
I'm in Michigan. Are there any pl1 jobs available anywhere these days? Any tele-commuting jobs? ...

51 to 53 migration issue
Can anyone point me in the right direction on an issue we are encountering during a 5.3 migration upgrade? In summary, we have attempted two migrations of 5.1 ML-05 to 5.3 ML-00. One was on an H70 and one on a p670. We also repeated the upgrade w/ a 5.3 ML-02 lpp source to see if the behavior was different but it was not. The migration seemed to go fine, but in both cases, after a few minutes of activity on the newly upgraded OS, we start encountering the following output: ------------------------------------------------------------ cernerdev is our p670: ----------------------------------...

Web resources about - Enterprise pl1 V3R8 to V4R1 migration issue (zOS) - comp.lang.pl1

Enterprise Apps Today - CRM, business intelligence and ERP news and research
News and research on CRM, business intelligence, ERP, supply chain management and other enterprise applications.

The Enterprise, MA News - Brockton, MA - The Enterprise
Was Keith Luke insane when he went on a rampage in Brockton on Jan. 21, 2009, killing two people and wounding another? Catch up on what people ...

VoIP Business, VoIP Technology, VoIP Security - Fierce Enterprise Communications
Visit FierceVoIP for the latest updates in VoIP business, unified communications, VoIP technology, mobile VoIP, VoIP security and more VoIP news. ...

HP Enterprise Services - Wikipedia, the free encyclopedia
HP Enterprise Services is the global business and technology services division of Hewlett Packard 's HP Enterprise Business strategic business ...

Defence department votes no on enterprise agreement by less than 2 per cent
Public servants at the Defence Department vote to reject pay offer by wafer-thin margin.

Forrester Wave: Best Enterprise Social Listening Platforms of Q1 Crowned
Forrester has recently announced the Forrester Wave of Q1 , crowning the top enterprise social listening platforms. Synthesio , Brandwatch , ...

Samsung Begins to Ship 15.36 TB SSD for Enterprise Storage Systems
Samsung on Thursday introduced its new lineup of high-capacity SSDs for enterprises. The new Samsung PM1633a family of drives includes the world’s ...

HP Enterprise Soars On Q4 Beat; Bernstein Ups To Buy
Hewlett Packard Enterprise ( HPE ) is jumping more than 15% after it reported a better-than-expected first quarter . Analysts are weighing in ...

Netskope launches threat protection for enterprise cloud apps
... or via a customer's existing SIEM solution. "With the constantly evolving landscape of malware, ransomware and other threats to the enterprise, ...

Hewlett Packard Enterprise beats on profits, stock climbs in after hours trading
Hewlett-Packard Enterprise has released its Q1 2016 earnings, its first full quarter results since HP split into two companies. HPE is the part ...

Resources last updated: 3/5/2016 2:37:00 AM