Joined: 10 Dec 2004 Posts: 110 Topics: 8 Location: Colorado USA
Posted: Tue Dec 06, 2005 1:01 pm Post subject:
I do not have any problem delclaring the table in the manner you specified. Can you post the portion of your listing with the errors? This is a rather large table though, so perhaps a rethinking of the design is in order.......
________
Yamaha CS30/CS30L synthesizer specifications
Last edited by dtf on Tue Feb 01, 2011 2:04 pm; edited 1 time in total
A redesign of this Table (and it's processing) is in order. This cannot possibly work, even if you can get it to assemble (by using GOFF for example). The basic problem is one of addressability. A single (base) register can only address 4096 bytes, two base registers gives you 8192 etc.
Huge amounts of data like this can only be handled inside a GETMAIN area. The best way to process a huge (variable) amount of data like this would be to adapt the code-sample given by Carmine Cannatello for "Building an Expandable Variable-Length Table". Have a look on the CBT tape at file 69, and the PDS member is "CE050801". By using Carmine's method you will not be needlessly reserving huge amounts of virtual and using only a fraction of it (because your table is variable). This code creates a series of GETMAIN areas, and each area contains a pointer to the next area, ad infinitum. The number of GETMAINs issued will vary, depending upon how much storage is required.
However, seeing as you have come up with this unworkable design, I would also question whether or not you really need to store such a large amount of data in the first place. Re-examine your options.
Carmine's code is below (in case you cannot FTP to your mainframe):
Code:
*
* CODING EXAMPLE 5.8.1
*
*
EXPDTBL CSECT
*
*
***********************************************************************
* INITIALIZATION
***********************************************************************
*
INITL 3,EQU=R INITIALIZE PROGRAM
*
*
***********************************************************************
* MAINSTREAM OF PROGRAM
***********************************************************************
*
...
BAL R6,ALLOBASE ALLOCATE TABLE BASE
NEXTDATA BAL R6,GETDATA GET A DATA RECORD
BAL R6,BLDTBL PUT RECORD INTO TABLE
B NEXTDATA GET NEXT DATA RECORD
DATAEND BAL R6,SETBLEND SET END OF DATA INDICATOR
...
*
*
***********************************************************************
* THIS ROUTINE ALLOCATES THE VIRTUAL STORAGE FOR THE TABLE BASE. THE
* ADDRESS OF THE FIRST TABLE SLOT IS STORED IN SLOTPTR AND THE TOTAL
* NUMBER OF SLOTS IN THE BASE AREA IN STORED IN SLOTCT.
***********************************************************************
*
ALLOBASE GETMAIN EC,LV=GM1LEN,SP=10,A=GM1ADDR
MVC SLOTPTR,GM1ADDR STORE FIRST AVAIL SLOT ADDR
LA R10,BASECT+1 LOAD NUMBER OF SLOTS IN GM1 AREA
ST R10,SLOTCT STORE NUMBER OF SLOTS
BR R6 RETURN TO CALLING RTN
*
*
***********************************************************************
* THIS ROUTINE GETS THE DATA FOR THE EXPANDABLE TABLE FROM SOME
* EXTERNAL SOURCE AND PLACES THE DATA ENTRY INTO THE AREA DATA.
***********************************************************************
*
GETDATA DS 0H
... GET DATA FROM EXTERNAL SOURCE
BR R6 RETURN TO CALLING RTN
*
*
***********************************************************************
* THIS ROUTINE BUILDS THE EXPANDABLE TABLE BY INSERTING THE DATA,
* WHICH IS PASSED TO IT IN THE AREA DATA, INTO THE TABLE SLOTS. THE
* ADDRESS OF THE NEXT SLOT IN STORED IN SLOTPTR AND THE NUMBER OF
* SLOTS LEFT IN THE TABLE SEGMENT IS STORED IN SLOTCT. THIS ROUTINE
* DOES THE FOLLOWING:
* * INSERTS THE DATA ENTRY INTO THE TABLE SLOT POINTED TO BY
* SLOTPTR;
* * UPDATES SLOTPTR TO POINT TO THE NEXT TABLE SLOT;
* * UPDATES SLOTCT BY DECREMENTING THE COUNT BY ONE;
* * BRANCHES AND LINKS TO THE ALLOXTEN ROUTINE TO ALLOCATE
* VIRTUAL
* STORAGE FOR ANOTHER TABLE SEGMENT WHEN THE CURRENT SEGMENT
* IS EXHAUSTED.
* THE INITIAL VALUES OF SLOTPTR AND SLOTCT ARE SET EACH TIME THAT
* VIRTUAL STORAGE IS ALLOCATED FOR A NEW TABLE SEGMENT BY THE
* ROUTINE WHICH DOES THE ALLOCATION.
***********************************************************************
*
BLDTBL L R10,SLOTCT LOAD NUMBER OF AVAIL SLOTS
BCTR R10,0 DECR AVAIL SLOT COUNT
LTR R10,R10 CHECK IF LAST SLOT
BZ LASTSLOT IF YES, BRANCH
L R11,SLOTPTR LOAD ADR OF NEXT AVAIL SLOT
MVC 0(ENTRYLEN,R11),DATA MOVE DATA INTO TABLE
LA R11,ENTRYLEN(0,R11) INCR TO NEXT SLOT ADDR
ST R11,SLOTPTR STORE ADR OF NEXT AVAIL SLOT
BR R6 RETURN TO CALLING RTN
LASTSLOT MVC SLOTXPTR,SLOTPTR STORE ADR OF LAST SLOT
BAL R7,ALLOXTEN OBTAIN NEXT GM AREA
L R11,SLOTXPTR LOAD ADR OF LAST SLOT OF PREV GM
MVC 0(4,R11),BINONES SET LINK WORD IN PREV GM AREA
MVC 4(4,R11),GMXADDR STOR ADR OF NEXT GM INTO PREV GM
B BLDTBL PUT CURRENT DATA ENTRY INTO TBL
*
*
***********************************************************************
* THIS SUBROUTINE ALLOCATES VIRTUAL STORAGE FOR A TABLE EXTENSION.
* IT RECEIVES CONTROL EACH TIME THAT THE CURRENT TABLE SEGMENT IS
* EXHAUSTED AND INITIALIZES THE SLOTPTR AND SLOTCT AREAS EACH TIME
* THAT ADDITIONAL VIRTUAL STORAGE IS ALLOCATED.
***********************************************************************
*
ALLOXTEN GETMAIN EC,LV=GMXLEN,SP=10,A=GMXADDR
MVC SLOTPTR,GMXADDR STORE FIRST AVAIL SLOT ADDR
LA R10,EXTENCT+1 LOAD NUMBER OF SLOTS IN GMX AREA
ST R10,SLOTCT STORE NUMBER OF SLOTS
BR R7 RETURN TO CALLING RTN
*
*
***********************************************************************
* THIS ROUTINE RECEIVES CONTROL WHEN ALL THE DATA IS INSERTED INTO
* THE TABLE AND PUTS AN END-OF-TABLE INDICATOR AFTER THE LAST DATA
* ENTRY.
***********************************************************************
*
SETBLEND L R11,SLOTPTR LOAD ADR OF NEXT AVAIL SLOT
MVC 0(4,R11),BINZEROS SET END-OF-DATA INDICATOR
BR R6 RETURN TO CALLING RTN
*
*
***********************************************************************
* DC/DS/EQU STATEMENTS
***********************************************************************
*
ENTRYLEN EQU 100 LENGTH OF DATA ENTRY
BASECT EQU 500 CAPACITY OF TABLE BASE
EXTENCT EQU 75 CAPACITY OF EACH TABLE EXTENSION
GM1LEN EQU (BASECT+1)*ENTRYLEN LENGTH OF BASE GETMAIN
GMXLEN EQU (EXTENCT+1)*ENTRYLEN LEN OF EACH ADDITIONAL GETMAIN
BINZEROS DC 4XL1'00' END-OF-DATA INDICATOR
BINONES DC 4XL1'FF' LINK INDICATOR
GM1ADDR DS F ADR OF BG OF TABLE
GMXADDR DS F ADR OF EACH TABLE EXTNSION
SLOTPTR DS F RUNNING ADR OF NEXT AVAIL SLOT
SLOTXPTR DS F ADR OF LAST SLOT OF EACH GM AREA
SLOTCT DS F RUNNING COUNT OF SLOTS AVAIL
DATA DS CL100 DATA ENTRY
...
*
*
***********************************************************************
SLOTCT DS F RUNNING COUNT OF SLOTS AVAIL
DATA DS CL100 DATA ENTRY
...
*
*
***********************************************************************
* END OF PROGRAM
***********************************************************************
*
END
Joined: 10 Dec 2004 Posts: 110 Topics: 8 Location: Colorado USA
Posted: Tue Dec 06, 2005 11:01 pm Post subject:
Quote:
The basic problem is one of addressability. A single (base) register can only address 4096 bytes, two base registers gives you 8192 etc.
I agree that this is probably not the way to handle this, however the base register addressability is not really a problem. Looping through the table (searching), would only require that you be able to address the first byte of the table. Once this was accomplished, you could easily loop through by incrementing the value of that register.
Certainly tables can be very large........
________
clear trichomes
Last edited by dtf on Tue Feb 01, 2011 2:04 pm; edited 1 time in total
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
