🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: comp.lang.asm370
11 messages
11 total messages Started by David P.C. Wollmann Fri, 25 Jul 1997 00:00
DSECT for MVS PDS vol def block?
#1013
Author: David P.C. Wollmann
Date: Fri, 25 Jul 1997 00:00
13 lines
1185 bytes
I am writing a PC program to extract members from a PDS binary. I have all
the information I need on the PDS directory structure, but haven't been
able to find a definition for the volume definition block. Is this
available in any BM books that I might be able to find online?

If I understand correctly, the voldef tells me if the PDS is ISPF, etc.,
creat date, expiration date, record size, etc. I need this information to
handle conversion from fixed records to DOS variable length (CR/LF), etc.

Thanks in advance,
Dave Wollmann
ibmstuff@oknet.com
Re: DSECT for MVS PDS vol def block?
#1014
Author: Shmuel (Seymour J.) Metz
Date: Mon, 28 Jul 1997 00:00
32 lines
1930 bytes
There is nothing in the directory entry called a volume definition
block. The ISPF data, if present, are in the user data field of the DE.
Record format, LRECL and BLKSIZE are kept in the DSCB1, not in the
directory, and apply to the entire PDS. You may be able to find the
layout of the ISPF data in the ISPF manuals, but I doubt it.

	Shmuel (Seymour J.) Metz

David P.C. Wollmann wrote:
> 
> I am writing a PC program to extract members from a PDS binary. I have all
> the information I need on the PDS directory structure, but haven't been
> able to find a definition for the volume definition block. Is this
> available in any BM books that I might be able to find online?
> 
> If I understand correctly, the voldef tells me if the PDS is ISPF, etc.,
> creat date, expiration date, record size, etc. I need this information to
> handle conversion from fixed records to DOS variable length (CR/LF), etc.
> 
> Thanks in advance,
> Dave Wollmann
> ibmstuff@oknet.com

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz.
Re: DSECT for MVS PDS vol def block?
#1005
Author: Michael Quinlan
Date: Mon, 04 Aug 1997 00:00
27 lines
1452 bytes
edjaffe@netcom.com (Edward E. Jaffe) wrote:

>
>In OS/390 V1R3.0 ISPF Dialog Developer's Guide and Reference, topic
>"C.2.4", I see:=20
>
>[------------------------- Begin IBM Documentation =
----------------------]
> C.2.4  ISPF Statistics Entry in a PDS Directory
>
> [...snipped...]
>
>   9-12     Date last modified:
>
>            Byte 9     Reserved for future IBM use
>            Byte 10-12 Julian date, in packed decimal format

Does this mean that ISPF is not Y2K compliant? 3 packed bytes only allows
for 5 digits (i.e. the old YY.DDD format). Or does byte 9 have the =
century
indicator?

--
Michael Quinlan
mikeq@primenet.com
http://www.primenet.com/~mikeq
Re: DSECT for MVS PDS vol def block?
#1015
Author: Edward E. Jaffe
Date: Mon, 04 Aug 1997 00:00
72 lines
3461 bytes
Shmuel (Seymour J.) Metz (nospam@gsg.eds.com) wrote:
: You may be able to find the
: layout of the ISPF data in the ISPF manuals, but I doubt it.

In OS/390 V1R3.0 ISPF Dialog Developer's Guide and Reference, topic
"C.2.4", I see: 

[------------------------- Begin IBM Documentation ----------------------]
 C.2.4  ISPF Statistics Entry in a PDS Directory

   The following is the format of the information that ISPF writes to the PDS
   directory to maintain statistics for a member.  If you suspect the
   statistics data has been corrupted, you can compare the existing entry
   against these formats to help in problem determination.

   Byte     Description and Format

   1        Version number, in hexadecimal format.  Value is between X'01'
            and X'99'.

   2        Modification level, in hexadecimal format.  Value is between
            X'00' and X'99'.

   3        Flags:

            Bit 1    SLCM indicator.  SCLM uses this to determine whether the
                     member and any related SCLM information are still in
                     sync.
                     o   ON means the member was last edited by SCLM, the PDF
                         Software Configuration and Library Manager.

                     o   OFF means the member was somehow processed outside
                         SCLM.

            Bit 2-8  Reserved for future ISPF use.

   4        The seconds portion of the time last modified, in packed decimal
            format.

   5-8      Creation date:

            Byte 5    Reserved for future ISPF use.
            Byte 6-8  Julian date, in packed decimal format

   9-12     Date last modified:

            Byte 9     Reserved for future IBM use
            Byte 10-12 Julian date, in packed decimal format

   13-14    Time last modified, in packed format:

            Byte 13  Hours, in packed decimal format
            Byte 14  Minutes, in packed decimal format

   15-16    Current number of lines, in hexadecimal format

   17-18    Initial number of lines, in hexadecimal format

   19-20    Number of modified lines, in hexadecimal format

   21-27    Userid, in character format

   28-30    Reserved for future ISPF use
[-------------------------- End IBM Documentation -----------------------]

-- 
| Edward E. Jaffe                | Voice:       (310) 338-0400 x318    |
| Mgr, Research & Development    | Facsimile:   (310) 338-0801         |
| Phoenix Software International | Internet:    edjaffe@netcom.com     |
| 9841 Airport Blvd, Suite 700   | IBM Mail:    USS24J24 at IBMMAIL    |	
| Los Angeles, CA 90045          | Phoenix BBS: Edjaffe (310) 417-8085 |
Re: DSECT for MVS PDS vol def block?
#1006
Author: smyers
Date: Tue, 05 Aug 1997 00:00
53 lines
2466 bytes
Packed decimal means 2 decimal digits in each byte, except for the
last byte, where the last 4 bits are a sign, based on the following
rule --
F - +
E - +
D - -
C - +
B - -
A - +

So, the 4 bytes are 0cyydddF, where F is the sign (a plus).  This is
really reg 1 after an old fashioned TIM macro.  January 1, 1999 will be
0099001F.  December 31, 1999 will be 099365F.  January 1, 2000 will be
0100001F.  The last 4 bits will be an F by the way, even though the
hardware prefers C for a plus sign after packed decimal arithmetic.

 <33e67399.691214@news.primenet.com>, mikeq@primenet.com (Michael Quinlan) writes:
>edjaffe@netcom.com (Edward E. Jaffe) wrote:
>
>>
>>In OS/390 V1R3.0 ISPF Dialog Developer's Guide and Reference, topic
>>"C.2.4", I see:=20
>>
>>[------------------------- Begin IBM Documentation =
>----------------------]
>> C.2.4  ISPF Statistics Entry in a PDS Directory
>>
>> [...snipped...]
>>
>>   9-12     Date last modified:
>>
>>            Byte 9     Reserved for future IBM use
>>            Byte 10-12 Julian date, in packed decimal format
>
>Does this mean that ISPF is not Y2K compliant? 3 packed bytes only allows
>for 5 digits (i.e. the old YY.DDD format). Or does byte 9 have the =
>century
>indicator?
>
>--
>Michael Quinlan
>mikeq@primenet.com
>http://www.primenet.com/~mikeq


-- Steve Myers

The E-mail addresses in this message are private property.  Any use of them
to  send  unsolicited  E-mail  messages  of  a  commerical  nature  will be
considered trespassing,  and the originator of the message will be  sued in
small claims court in Camden County,  New Jersey,  for the  maximum penalty
allowed by law.
Re: DSECT for MVS PDS vol def block?
#1007
Author: smyers
Date: Tue, 05 Aug 1997 00:00
15 lines
1439 bytes
Mike --

It took some doing, but the OS/390 1.3 manual for ISPF clearly states the
two bytes are used for the century indication.

See http://ppdbooks.pok.ibm.com:80/cgi-bin/bookmgr/bookmgr.cmd/BOOKS/ISPMES01/8/2/4

-- Steve Myers

The E-mail addresses in this message are private property.  Any use of them
to  send  unsolicited  E-mail  messages  of  a  commerical  nature  will be
considered trespassing,  and the originator of the message will be  sued in
small claims court in Camden County,  New Jersey,  for the  maximum penalty
allowed by law.
Re: DSECT for MVS PDS vol def block?
#1008
Author: Jim Van Sickle
Date: Tue, 05 Aug 1997 00:00
28 lines
1684 bytes
smyers@popmail.voicenet.com wrote:
> 
> Mike --
> 
> It took some doing, but the OS/390 1.3 manual for ISPF clearly states
> the
> two bytes are used for the century indication.
> 
> See
> http://ppdbooks.pok.ibm.com:80/cgi-bin/bookmgr/bookmgr.cmd/BOOKS/ISPMES01/8/2/4
> 
> -- Steve Myers

Who the heck would have thought to look in the "Messages and Codes"
manual for the ISPF Statistics Entry in a PDS Directory?!?! 

IBM strikes again :-) 

-- 
***********************************************
*   Jim Van Sickle <mailto:jim.vs@ibm.net>    *
*    Manager, Operations and Tech Support     *
*             United Retail, Inc.             *
*---------------------------------------------*
*         visit my meager web site at:        *
*    <http://mypage.ihost.com/jimswebsite/>   *
***********************************************
Re: DSECT for MVS PDS vol def block?
#1009
Author: Michael Quinlan
Date: Tue, 05 Aug 1997 00:00
61 lines
2522 bytes
smyers@popmail.voicenet.com wrote:

>Packed decimal means 2 decimal digits in each byte, except for the
>last byte, where the last 4 bits are a sign, based on the following
>rule --
>F - +
>E - +
>D - -
>C - +
>B - -
>A - +

I am fully aware of the packed decimal format.

>So, the 4 bytes are 0cyydddF, where F is the sign (a plus).  This is

Where do you find four bytes? Bytes 10-12. Byte 10, byte 11, and byte 12.
When I count, that comes to three bytes, not four bytes.

> <33e67399.691214@news.primenet.com>, mikeq@primenet.com (Michael =
Quinlan) writes:
>>edjaffe@netcom.com (Edward E. Jaffe) wrote:
>>
>>>
>>>In OS/390 V1R3.0 ISPF Dialog Developer's Guide and Reference, topic
>>>"C.2.4", I see:=3D20
>>>
>>>[------------------------- Begin IBM Documentation =3D
>>----------------------]
>>> C.2.4  ISPF Statistics Entry in a PDS Directory
>>>
>>> [...snipped...]
>>>
>>>   9-12     Date last modified:
>>>
>>>            Byte 9     Reserved for future IBM use
>>>            Byte 10-12 Julian date, in packed decimal format
>>
>>Does this mean that ISPF is not Y2K compliant? 3 packed bytes only =
allows
>>for 5 digits (i.e. the old YY.DDD format). Or does byte 9 have the =3D
>>century
>>indicator?
>
>-- Steve Myers
>
>The E-mail addresses in this message are private property.  Any use of =
them
>to  send  unsolicited  E-mail  messages  of  a  commerical  nature  will=
 be
>considered trespassing,  and the originator of the message will be  sued=
 in
>small claims court in Camden County,  New Jersey,  for the  maximum =
penalty
>allowed by law.

--
Michael Quinlan
mikeq@primenet.com
http://www.primenet.com/~mikeq
Re: DSECT for MVS PDS vol def block?
#1010
Author: Paolo Bandini
Date: Thu, 07 Aug 1997 00:00
17 lines
1604 bytes
giprice@ibm.net wrote:

> Just for the sake of it, I'll say that ISPF checks that the
> 2 bytes after the 8-byte userid field are blank.  If they
> aren't blank, ISPF does not treat the member userdata
> as SPF statistics.  I continue to ramble to the effect that
> Fujitsu decided to save that halfword and reduced PFD
> (not PDF) statistics to 14 halfwords.  Last time I checked
> PFD still understood the original 15 h/w format.  Must be
> time for my medication.  Bye.
> Greg

Not only the two last byte must be blank, but the last byte of Userid
must be blank too.
Of course we cannot have a 8-bytes userid, but we cannot use that field
for true 8-bytes data.
Re: DSECT for MVS PDS vol def block?
#1011
Author: David P.C. Wollmann
Date: Fri, 08 Aug 1997 00:00
28 lines
1614 bytes
FWIW, an earlier description of the PDS directory spec stated that the the
bytes in question were 'reserved for future use.' I guess the future is
here.






On Tue, 05 Aug 1997 19:14:47 -0400, Jim Van Sickle <jim.vs@ibm.net> wrote:

>smyers@popmail.voicenet.com wrote:
>> 
>> Mike --
>> 
>> It took some doing, but the OS/390 1.3 manual for ISPF clearly states
>> the
>> two bytes are used for the century indication.
>> 
>> See
>> http://ppdbooks.pok.ibm.com:80/cgi-bin/bookmgr/bookmgr.cmd/BOOKS/ISPMES01/8/2/4
>> 
>> -- Steve Myers
>
>Who the heck would have thought to look in the "Messages and Codes"
>manual for the ISPF Statistics Entry in a PDS Directory?!?! 
>
Re: DSECT for MVS PDS vol def block?
#1012
Author: William Lynch
Date: Fri, 08 Aug 1997 00:00
35 lines
1923 bytes
FWIW, Jim's response reminds me of the Leonard Cohen song "The Future",
"...I have seen the future, brother. It is murder."

Bill Lynch

David P.C. Wollmann <ibmstuff@oknet.com> wrote in article
<33eb3e32.8931058@news.swbell.net>...
> FWIW, an earlier description of the PDS directory spec stated that the
the
> bytes in question were 'reserved for future use.' I guess the future is
> here.
> 
> 
> On Tue, 05 Aug 1997 19:14:47 -0400, Jim Van Sickle <jim.vs@ibm.net>
wrote:
> 
> >smyers@popmail.voicenet.com wrote:
> >> 
> >> Mike --
> >> 
> >> It took some doing, but the OS/390 1.3 manual for ISPF clearly states
> >> the
> >> two bytes are used for the century indication.
> >> 
> >> See
> >>
http://ppdbooks.pok.ibm.com:80/cgi-bin/bookmgr/bookmgr.cmd/BOOKS/ISPMES01/8/
2/4
> >> 
> >> -- Steve Myers
> >
> >Who the heck would have thought to look in the "Messages and Codes"
> >manual for the ISPF Statistics Entry in a PDS Directory?!?! 
> >
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads