date:20111026

Re: GDG

2011-10-26 Thread Robert A. Rosenberg


At 14:52 -0700 on 10/25/2011, Steve Thompson wrote about Re: GDG:

Do you actually mean version or generation? I ask this because now 
and then someone actually means version (rarely). And what you asked 
could be either.


Version will be A.B.C.G0001V00  then A.B.C.G0001V01.

Generation will be A.B.C.G0001V00 then A.B.C.G0002V00

This makes a big difference in what you will have to do!!


Note that when you create and catalog A.B.C.G0001V01 it will replace 
A.B.C.G0001V00 as A.B.C(n) - IOW: If after A.B.C.G0002V00 was created 
A.B.C.G0001V00 would be A.B.C(-1). Creating A.B.C.G0001V01 at this 
point would make IT A.B.C(-1) and A.B.C.G0001V00 would no longer be 
cataloged (it would be handled just like a generation that rolled off 
the GDG base.


The purpose of creating a GVyy (where yy is NOT 00) is to replace 
the V00 (or current) version. This might occur if you want move the 
file from one media to another while leaving it in the GDG chain.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Looking for clues on a bug in assembler

2011-10-26 Thread Robert A. Rosenberg

At 05:54 -0700 on 10/25/2011, Charles Mills wrote about Re: Looking 
for clues on a bug in assembler:



My conclusion was the following sequence -- and there may be other details
that are significant, but this is my best guess as to the significant
details:

1. OPEN DCB, no error
2. GET DCB -- Drives SYNAD exit as expected
3. CLOSE DCB, no error reported
4. OPEN DCB, no error
5. GET, GET, GET, ..., GET (last record), GET -- QSAM branches to random
address, not the specified EOD address -- S0C4

However, if between steps 3 and 4 I add a step to restore the DCB to the
values it had before step 1, then all works as expected.

This behavior is contrary to the clearly stated QSAM CLOSE documentation:
The fields of the data control block (DCB) and DCBE are restored to the
condition that existed before the OPEN macro was issued, and the data set is
disconnected from the processing program.


Have you tried writing a sanity check program? Have it do steps 1-3 
and compare what is in the EOD field before and after steps 1 and 3. 
If the field has not been restored then this should catch it. Also 
try doing a compare of the copy of the DCB that you use for the 
restore with the DCB which was opened and closed. That should show a 
bad restore. Doing snap shot dumps of the DCB and DCBE at each stage 
should show the failure. Sending that in should help document the 
problem as it occurs.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Looking for clues on a bug in assembler

2011-10-26 Thread Elardus Engelbrecht

Ed Gould wrote:

When we were debugging the many bugs in the first PSF we had the occasions to 
send listings to the PSF people along with various traces etc etc. I always 
asked the user if there were any issues with sending sensitive  data (trading 
information)  he asked who we were sending it to and when we told him IBM, he 
said no problem.

Agreed. Thanks Ed. Big Blue has formal agreements and documentations just for 
that.

Look for these two pages for example:

'Exchanging diagnostic data with IBM' -

http://www-05.ibm.com/de/support/ecurep/service.html

'Agreement for exchange of confidential information' - 

http://www-304.ibm.com/businesscenter/cpe/download0/186137/aeci_us.pdf

There are more such pages.

Ok, I'm now leaving this thread, I'm tired of it... grin :-D

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Dynamic calls in Binder sysprint

2011-10-26 Thread K Zafirop

Thank you all for your responses.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

SV: GDG

2011-10-26 Thread Thomas Berg

 -Ursprungligt meddelande-
 Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För
 Robert A. Rosenberg
 Skickat: den 26 oktober 2011 07:27
 Till: IBM-MAIN@bama.ua.edu
 Ämne: Re: GDG
 
 At 14:52 -0700 on 10/25/2011, Steve Thompson wrote about Re: GDG:
 
 Do you actually mean version or generation? I ask this because now
 and then someone actually means version (rarely). And what you asked
 could be either.
 
 Version will be A.B.C.G0001V00  then A.B.C.G0001V01.
 
 Generation will be A.B.C.G0001V00 then A.B.C.G0002V00
 
 This makes a big difference in what you will have to do!!
 
 Note that when you create and catalog A.B.C.G0001V01 it will replace
 A.B.C.G0001V00 as A.B.C(n) - IOW: If after A.B.C.G0002V00 was created
 A.B.C.G0001V00 would be A.B.C(-1). Creating A.B.C.G0001V01 at this
 point would make IT A.B.C(-1) and A.B.C.G0001V00 would no longer be
 cataloged (it would be handled just like a generation that rolled off
 the GDG base.
 
 The purpose of creating a GVyy (where yy is NOT 00) is to replace
 the V00 (or current) version. This might occur if you want move the
 file from one media to another while leaving it in the GDG chain.
 

By curiosity, how do You specify version in the JCL ?  
I mean in the same way we specify latest generation by aaa(0) 
and a new by aaa(+1) etc. 


 
Regards, 
Thomas Berg 
_ 
Thomas Berg   Specialist   A M   SWEDBANK 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SV: GDG

2011-10-26 Thread R.S.

W dniu 2011-10-26 12:09, Thomas Berg pisze:

-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För
Robert A. Rosenberg
Skickat: den 26 oktober 2011 07:27
Till: IBM-MAIN@bama.ua.edu
Ämne: Re: GDG

At 14:52 -0700 on 10/25/2011, Steve Thompson wrote about Re: GDG:

Do you actually mean version or generation? I ask this because now
and then someone actually means version (rarely). And what you asked
could be either.

Version will be A.B.C.G0001V00 then A.B.C.G0001V01.

Generation will be A.B.C.G0001V00 then A.B.C.G0002V00

This makes a big difference in what you will have to do!!

Note that when you create and catalog A.B.C.G0001V01 it will replace
A.B.C.G0001V00 as A.B.C(n) - IOW: If after A.B.C.G0002V00 was created
A.B.C.G0001V00 would be A.B.C(-1). Creating A.B.C.G0001V01 at this
point would make IT A.B.C(-1) and A.B.C.G0001V00 would no longer be
cataloged (it would be handled just like a generation that rolled off
the GDG base.

The purpose of creating a GVyy (where yy is NOT 00) is to replace
the V00 (or current) version. This might occur if you want move the
file from one media to another while leaving it in the GDG chain.

By curiosity, how do You specify version in the JCL ?
I mean in the same way we specify latest generation by aaa(0)
and a new by aaa(+1) etc.

You specify DSN=HLQ.GDGBASE.G0008V01,DISP=(,CATLG)
It will REPLACE HLQ.GDGBASE.G0008V00 - the older version will be deleted.
Actually you can specify V07 jsut after V00, or even V03 after V07. In
any case the newest version will be kpet, despite of the version number.

BTW: IMHO moving from one media to another is bad example. It can be
done by using DSS COPY with TGTGDS option.
Versions are for unsuccesful job runs. You can rerun the job and create
another version.

--
Radoslaw Skorupka
Lodz, Poland

--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax
+48 (22) 829 00 33, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88.
Wedug stanu na dzie 01.01.2011 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.346.696 zotych.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

75 matches

Mail list logo